アカウント名:
パスワード:
VS2019 を起動しても、devenv はそんなには使っていない印象なんですけどそれよりも、ServiceHub とかの vsHost とかのサブプロセスが結構使っていて、トータル 4GB 超みたいな# とはいえ 64bit への統一は歓迎です
使わない。だからデモでも大量ファイルを開くというあまりないことやってるし、今まで不満も出ていなかった。それでもパフォーマンスの向上やら、なんかメモリリークがあっても落ちないやら、悪いことじゃない。32ビットで作ったプラグインはたぶん書き換えてもらわないといけないけど。
2、3世代ぐらい前から、プラグインも.NETネイティブになってるので、昔からのものとかメンテナンスされてないやつ以外は問題ない。
メモリに関しては、32bitプロセスの制限(2GB)で足りてなくて、外部プロセスに投げて処理してるところが結構あるから、そこがインプロセスになると、同期ずれで「反応なし」になることが少なくなる期待はあるな。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
未知のハックに一心不乱に取り組んだ結果、私は自然の法則を変えてしまった -- あるハッカー
devenv.exe 単品で 4GB も使ったっけ? (スコア:0)
VS2019 を起動しても、devenv はそんなには使っていない印象なんですけど
それよりも、ServiceHub とかの vsHost とかのサブプロセスが結構使っていて、トータル 4GB 超みたいな
# とはいえ 64bit への統一は歓迎です
Re: (スコア:0)
使わない。
だからデモでも大量ファイルを開くというあまりないことやってるし、今まで不満も出ていなかった。
それでもパフォーマンスの向上やら、なんかメモリリークがあっても落ちないやら、悪いことじゃない。
32ビットで作ったプラグインはたぶん書き換えてもらわないといけないけど。
Re:devenv.exe 単品で 4GB も使ったっけ? (スコア:0)
2、3世代ぐらい前から、プラグインも.NETネイティブになってるので、昔からのものとかメンテナンスされてないやつ以外は問題ない。
メモリに関しては、32bitプロセスの制限(2GB)で足りてなくて、外部プロセスに投げて処理してるところが結構あるから、そこがインプロセスになると、同期ずれで「反応なし」になることが少なくなる期待はあるな。