マネージド アプリの 1 つが 20 ~ 25Mb の RAM を使用しているという苦情がいくつかありました。私は通常、メモリは安いと反論します。それを乗り越えてください。
これは、Windows フォーム アプリにとって合理的ですか?
20〜25MBは何もありません。
とにかく、.Net フレームワークは常に RAM をすぐにリサイクルするとは限りません。時間が経つにつれて、アプリが「高価な」プロセス中に数百 MB の RAM でピークに達し、「高価な」プロセスが終了した後もそこに留まるのを見てきました。ただし、これは誤解を招きます。アプリはこの RAM を使用していませんでした。ガベージ コレクタが大量の古い RAM を収集する必要性をまだ認識していないだけです。オペレーティング システムがその RAM を必要としている場合は、それが収集されるので安心してください。アプリはせいぜい数百 K しか使用しないという考えは、管理された環境には当てはまりません — オペレーティング システム プロセスについては、そうです。ネイティブアプリの場合はそうかもしれません。ただし、マネージド コードではありません。そうしないと、1 GB 以上の RAM を搭載したシステムがアイドル状態になるだけです。
その質問は、「部屋にりんごをいくつ入れられるか」と尋ねるようなものです...
まず「りんごの大きさは?」と反論しますが…?
だったら「部屋の広さ」で反論してみたら…?
これらの質問に答えると、大まかな見積もりを出すことができます。ただし、.Net (および Java も同様) の「Hello World」アプリケーションでさえ、数 KB から数百テラバイト (理論上) のデータを消費する可能性があることに注意してください。使用可能なメモリの量に応じて、プール内に極端な量のメモリを配置する必要があります。したがって、メモリが不足しているコンピューターでは、.Net WinForms アプリは少量しか使用しない場合がありますが、大量の空きメモリがあるシステムでは、「Hello World」でも(理論的には)テラバイトかかる場合があります...
それはかなり合理的です、はい。より頻繁に GC を実行して積極的にヒープ サイズを抑えようとするよりも、もう少し多くのメモリを割り当てる方が安価です。
プッシュバックには正当な理由が考えられます: 顧客がターミナル サービス環境でアプリを使用していて、10 人以上のユーザーが 4 GB の RAM を共有している場合はどうなるでしょうか? 20 ~ 25 MB を Outlook の 30+、IE の 20+、Word の 25+、Excel の 25+ に追加し、端末ユーザーの数を掛けると、それらがどこから来たのかがわかります。
私は、この時代では、20 - 25 MB が完全に合理的だと思います。あなたが数百メガにいる場合、それは別の話かもしれません. しかし、それはすべて状況によって異なります。
RAMとは実際にはどういう意味ですか? ワーキング セット、プライベート ワーキング セット、仮想メモリなどですか。かなり単純な .Net アプリを起動したところ、21MB のワーキング セット、つまり 21MB の RAM を占有していました。しかし、そのプライベート ワーキング セットは 4MB しかないため、アプリが読み込まれていない場合でも使用されるシステム ライブラリと共有ライブラリによって約 17MB が使用されます。
次に、アプリでかなりメモリを集中的に使用する作業を行ったところ、プライベート ワーキング セットは 28MB に達しました。次に、メモリを大量に消費する別のアプリに切り替えたところ、メモリが解放されていないにもかかわらず、プライベート ワーキング セットが 8MB になりました。
アプリケーションの RAM 使用量を測定するのは非常に難しく、メモリ使用量が「多すぎる」かどうかを判断するのはさらに困難です (もちろん、とんでもないことは別として)。
クライアントが慎重に考え抜かれたパフォーマンス カウンター測定値を使用して、さまざまな種類のメモリ使用量を示していない限り、アプリがコンピューターで使用しているメモリ量を実際に把握することはできません。
実際にはメモリの問題はありませんが、クライアントの技術的なノウハウによっては、潜在的に厄介な通信の問題があります。しかし、RAM が安いというのは少しひっくり返るように聞こえ、最良のアプローチではないかもしれません。
アプリが何をしているかによって異なります。20 - 25Mb は私にはあまり聞こえません。
私は非常に単純な Windows フォーム アプリを作成しましたが、そのアプリには 19 ~ 20Mb しかかかりませんでした。これはおそらく、.NET フォーム アプリケーションが必要とするメモリの最小量に近いと思います。
いいえ、それは完全に法外です。あなたは自分自身をプログラマーと呼んでいますか?なんてこった、男。私が始めたとき、1 枚のパンチ カードに 15 のアプリケーションを収めることができました (さびた足の爪切りでパンチする必要がありました)。それらはすべて 15 CPU サイクル以内に完了し、実際には何もないところからメモリを作成しました。
あなたは恥じるべき。さっさと辞任しろ。
何してるの?長編小説約20冊分の記憶を使い果たしてしまうのは正当なことでしょうか?それは間違いなくあなたのアプリであり、.net ランタイムのオーバーヘッドだけではありませんか? 問題のマシンのメモリが不足していませんか? パフォーマンスが低下しますか?
それと、他の何千もの質問に答える必要があります :) 個人的には、途方もなく膨大な量のメモリだと思います...しかし、私は携帯電話で作業しており、20MB が私がこれまでに得ることができる最大のものです。最大ヒープサイズ:)
ユーザーがタスク マネージャーを使用してアプリのメモリ使用量を確認している場合、おそらく [メモリ使用量] 列を確認しています。Stephen Martin が言っているように、これは誤解を招く可能性があります。なぜなら、その列は実際にはアプリの完全なワーキング セットを示しているからです。これは次のもので構成されています。
この場合、アプリの完全なワーキング セットをプライベート/共有ワーキング セットに手動で減らすことで、ちょっとしたトリックを行うことができます。これは、Win32 API 呼び出しSetProcessWorkingSetSize(GetCurrentProcess(), -1, -1)を使用して行われます。これは、システムのメモリが不足しているときに Windows が実行することですが、これがいつ発生するかを制御することで、.NET アプリの完全なワーキング セットをプライベート/共有ワーキング セットに取り除くことができます。通常、この数ははるかに小さくなります。
どれくらい小さい?アプリをタスクバーに最小化しても同じことが行われるため、コードを変更せずに確認できます。
アプリケーションのメモリ フットプリントで眉をひそめたことがある場合は、少なくとも、この量が本当に必要なのか、それとも非効率が蓄積されているだけなのかを少し確認する必要があります。多くの場合、メモリ フットプリントを削減すると速度も向上し、顧客の満足度も向上します。多くの場合、この種の苦情は、ユーザーの観点からは肥大化しているように見える他の非効率性を示唆している可能性もあります。