- PR -

常駐アプリケーション

«前のページへ 1|2|3|4|5 次のページへ»
投稿者投稿内容
なちゃ
ぬし
会議室デビュー日: 2003/06/11
投稿数: 872
投稿日時: 2007-04-29 16:42
とりあえず、

１．なんでスレッド関連が半前提として出てきているのか
なんでアプリの常駐でThreadかBackgroundWorkerかそれ以外
という選択肢が出ているのか。

２．レスポンスとメモリ使用量の意味詳細
メモリ使用量とは、アプリがトータルで使用する量なのか
起動した後でずっと使用しているといえるようなメモリ量なのか
メモリ量とは正確には何のことなのか。
※例によってタスクマネージャの「メモリ使用量」？

レスポンスとは起動から定常状態に変わるまでのレスポンスというような意味なのか、
なんらかの機能を提供しているとして、それが反応できるまでといった意味合いのレスポンスなのか、
あるいは何らか反応した後の処理完了までというような意味合いなのか、
それとも単になんとなく効率的な意味（なんとなくレスポンスとかいてみただけ）なのか。

３．レスポンスとメモリとどっちが重要なのか
上記１．２．がはっきりしたところでどっちがどの程度重要なのか
※レスポンスとメモリ使用量ってトレードオフにある場合が多いのでは？


が正確に分かればいいけど多分分からないような気がする。
なちゃ
ぬし
会議室デビュー日: 2003/06/11
投稿数: 872
投稿日時: 2007-04-29 16:56
それとも常駐とかはとりあえずおいといて、

スレッドを効率よく使うにはどんなやり方がよい的な話かしらん？
その場合にしても少なくともスレッドをどんな感じに使うのかで
当然変わってくるので答えられないですが。

・スレッド数がどのくらいになるのか
・各スレッドはいっせいに動作するのか、
・何らかのイベントを待ちながらばらばらに動くのか、
・長時間かかる処理なのか短時間の処理の繰り返しなのか、
・スレッドに関して何らかの制約あるいは操作が発生するのか（STA、MTAとか優先度とかその他いろいろ）
・ほんとに複数スレッドで同時に動作しなければならない理由があるのか
・そもそも処理を直列にして1スレッドがもっとも効率よいってなことはないのか？

で、考えられる条件がありすぎて、せめてどんな感じの操作か分からないとなんともいえません。


BackgroundWorker使うよりはThreadPoolを直に使う方が多少はいい可能性がありますが、
多くの場合そんなに変わらんでしょう。

Threadを直に使うのとThreadPoolを使うのとどっちがいいなら、条件によりますが
ThreadPoolを利用する方が効率的に行える可能性はあるでしょう。
が、ずっとスレッドが常駐しているような処理？では意味ない可能性もあります。


ThreadPoolを利用するに適したスレッドの使い方なら、
ThreadPoolを使うのがいいでしょう、多くの場合。

--追記
自分で必要な処理だけに特化したスレッドプール的な処理を自作するなら、
そっちの方が効率よくできるかもしれません。必要なことしかやらないので。

スレッドを新たに使わなくても問題ないようにおこなえる処理なら、
スレッド使わないのがいいですよ、多分。


[ メッセージ編集済み 編集者: なちゃ 編集日時 2007-04-29 17:05 ]
とっちゃん
大ベテラン
会議室デビュー日: 2005/07/19
投稿数: 203
投稿日時: 2007-04-30 12:12
引用:

ひまわりさんの書き込み (2007-04-26 09:07) より:

PC起動時から電源断または強制終了まで処理が続くアプリケーションをつくる場合、
１　Backgroundworker
２　System.Treading
３　または　それ以外？
のどれを使うのがメモリ消費が少なくてすむでしょうか？
どのコントロール（またはクラス）を使うのがメモリ消費が少ない
かを知りたいということです。
そのアプリケーションの使途は関係ないと思います。


メモリ消費を少なくしたいということのなので、

３ですね。

コントロールはメモリ消費が激しいので、使わない方がいいでしょう。
クラスも同様ですね。どうしたって、オーバーヘッドが出ます。
というより、.NET Framework 自身使わない方がいいですね。

かなりいろんなメモリを「余計に」消費してますよ。


これまでスレの流れをみると、起動(OS起動直後)から終了(シャットダウン直前)まで、長期間動くということを想定しているんだと思います。

なので、あらゆる面でメモリ消費は抑えたい。でも可能な限りレスポンス(応答性？)は確保したい。
ということなんだと勝手に想定しました。

メモリ消費を抑えるためには、極力メモリを必要としないプログラムの書き方を行う必要があります。

まず、選択肢として、.NET Framework の利用は外してください。
プログラムのソースからは見えないメモリをたくさん利用します。

プログラミング言語としては、アセンブラを選ぶのが一番良いと思います。
ソースコードにあることが全てになりますので、余計なメモリは一切消費しません。

どんなにコンパイラの性能が上がっても、ランタイムライブラリを必要とする限り余計なメモリを消費します。
なので、究極を求めるなら、アセンブラ以外の選択肢は未来永劫現れないと思いますよ。

レスポンスもよくなるし、パフォーマンスも絶対に下がりませんよ。
＃もちろん、コーディング次第ですけど。

_________________
// とっちゃん(高萩 俊行)＠わんくま同盟
// とっちゃん’Blog
// MS-MVP for Developer Tools - Visual C++
// WindowsInstallerの話題はhttp://www.freeml.com/msiまで
マーサ
ベテラン
会議室デビュー日: 2004/11/26
投稿数: 87
投稿日時: 2007-05-01 18:30
メモリ消費量はレスポンスを考えるなら、アセンブラが良いでしょうね。
ただシステムを壊す恐れがあるので、取り扱い注意ですがｗ

監視ソフト、キーロガー、ウィルス等効果的です！？
＃決して推奨している訳では有りません。止めて下さい。


VS.NET2005で考えている見たいなので、回答になってないかもしれませんが。。。
＃皆さんも言っているように、用途により効果的な部品が変わったりしますので・・・。
Jitta
ぬし
会議室デビュー日: 2002/07/05
投稿数: 6267
お住まい・勤務地: 兵庫県・海手
投稿日時: 2007-05-02 09:44
引用:

マーサさんの書き込み (2007-05-01 18:30) より:
メモリ消費量はレスポンスを考えるなら、アセンブラが良いでしょうね。
ただシステムを壊す恐れがあるので、取り扱い注意ですがｗ

監視ソフト、キーロガー、ウィルス等効果的です！？
＃決して推奨している訳では有りません。止めて下さい。


VS.NET2005で考えている見たいなので、回答になってないかもしれませんが。。。
＃皆さんも言っているように、用途により効果的な部品が変わったりしますので・・・。

なんか、勘違いが入っていませんか？
アセンブラ使わなくても、監視ソフトやキーロガー、ウィルスなど作れますよ？アンチ ウィルスなどにしても C 言語で作っているだろうし。
　とっちゃんさんがアセンブラを勧めているのは、ここ。
引用:

プログラミング言語としては、アセンブラを選ぶのが一番良いと思います。
ソースコードにあることが全てになりますので、余計なメモリは一切消費しません。

どんなにコンパイラの性能が上がっても、ランタイムライブラリを必要とする限り余計なメモリを消費します。

自分で書いたものしかない、ってところです。



> VS.NET2005で考えている見たいなので
ですね。
　つか、スレッド作るのに System.Threading.Thread 以外の方法はなく、Back... はそいつのラッパー。ラッパーなんだから、クラスを作る分、直接操作するより余分なメモリを食う。ただし、同じことは自分でコーディングしなければならないはずなので、「マイクロソフトより俺の方が上手に書けるゼ！」ってんならどうぞご自由に。
（Win32 直接コールという手もあるけど）
_________________
マーサ
ベテラン
会議室デビュー日: 2004/11/26
投稿数: 87
投稿日時: 2007-05-02 11:39
引用:

Jittaさんの書き込み (2007-05-02 09:44) より:
なんか、勘違いが入っていませんか？
アセンブラ使わなくても、監視ソフトやキーロガー、ウィルスなど作れますよ？アンチ ウィルスなどにしても C 言語で作っているだろうし。
　とっちゃんさんがアセンブラを勧めているのは、ここ。

勘違いと言うか、C言語ってコンパイルするとアセンブラ化されますよね？
しかも、分かりにくくｗ
自分で書いた方がコーディング量少なくて済みますし。
＃最近のコンパイラについては良く知りませんが。。。

そういう意味から言ってみました。
＃まぁ、言いたい事はとっちゃんさんと同じなのですが

[ メッセージ編集済み 編集者: マーサ 編集日時 2007-05-02 11:41 ]
とっちゃん
大ベテラン
会議室デビュー日: 2005/07/19
投稿数: 203
投稿日時: 2007-05-02 12:08
引用:

マーサさんの書き込み (2007-05-02 11:39) より:

勘違いと言うか、C言語ってコンパイルするとアセンブラ化されますよね？
しかも、分かりにくくｗ
自分で書いた方がコーディング量少なくて済みますし。


.NET も最終的にはアセンブラコードはきますよ。
通常は、JIT通しての実行時のみですが、NGEN使えば、事前にNativeコードに出来ます。

それと、アセンブラコードが分かりにくいのではなくて、元のソースと1対1のコードにはならないというだけですね。
コンパイラの最適化オプションをはずせば、1対1になります。

ま、キーロガーほかマルウェア類にせよ、ドライバ類にせよ最近ではほとんどが、ＣあるいはＣ＋＋を使ってると思いますけどねｗ
＃アセンブラでドライバなんてのは、前世紀の話ですからｗｗｗ

_________________
// とっちゃん(高萩 俊行)＠わんくま同盟
// とっちゃん’Blog
// MS-MVP for Developer Tools - Visual C++
// WindowsInstallerの話題はhttp://www.freeml.com/msiまで
マーサ
ベテラン
会議室デビュー日: 2004/11/26
投稿数: 87
投稿日時: 2007-05-02 13:11
引用:

とっちゃんさんの書き込み (2007-05-02 12:08) より:

.NET も最終的にはアセンブラコードはきますよ。
通常は、JIT通しての実行時のみですが、NGEN使えば、事前にNativeコードに出来ます。

それと、アセンブラコードが分かりにくいのではなくて、元のソースと1対1のコードにはならないというだけですね。
コンパイラの最適化オプションをはずせば、1対1になります。

.NETでもアセンブラ化してるんですね。
＃アセンブラは付いて回るものでしょうけど。

最適化オプションなしで１：１になるのですか！
知りませんでした、勉強になります。

引用:

ま、キーロガーほかマルウェア類にせよ、ドライバ類にせよ最近ではほとんどが、ＣあるいはＣ＋＋を使ってると思いますけどねｗ
＃アセンブラでドライバなんてのは、前世紀の話ですからｗｗｗ

確かに、アセンブラで組む仕事も周りで見なくなりましたし。
ＣやＣ＋＋の方が作りやすい（トッツキヤスイ）ですからねぇ。
＃時代の流れかなぁ。。。

_________________
C/C++大好き
«前のページへ 1|2|3|4|5 次のページへ»

スキルアップ／キャリアアップ（JOB@IT）