08/09/27 02:20:46
>>501
入れ替えできないってのは容易に入れ替えできないということだろ。
たとえば、本番環境で24時間稼働していてテスト環境では現象が再現しない場合など、メンテナンス時などに詳しくログはくものに入れ替えるとか。
511:デフォルトの名無しさん
08/09/27 19:24:17
デリゲートは本当に遅いの？
ただの仮想関数よりも？
512:デフォルトの名無しさん
08/09/27 19:27:35
どこで聞いてきたのさ？DynamicInvokeしなければ速いよ。
513:デフォルトの名無しさん
08/09/27 19:52:46
C＃なじてんで…
514:デフォルトの名無しさん
08/09/27 20:01:02
（インライン化されてない）普通のメソッド呼び出しと仮想関数呼び出しだって、
遅くなるのは間接参照1回分よ。
デリゲートはそれよりはちょっと遅いかも。
普通の関数ポインタよりも高機能なことやるのに色々オーバーヘッドかかってるだろうし。
515:デフォルトの名無しさん
08/09/27 21:08:04
ILも見ずに議論とな
516:デフォルトの名無しさん
08/09/27 21:13:50
ILからJITされた結果も確認せずに議（略ってどうやったら見れるのだろう。
仮想関数のオーバーヘッドはJITでほぼゼロになる。
インライン化もたいていJITでやってる。
517:デフォルトの名無しさん
08/09/27 21:19:54
ILはあんまり見ないけどJITコンパイル後のは時々見る
こっちの方が分かりやすい
518:デフォルトの名無しさん
08/09/27 21:42:40
C#のJITではC++でコンパイルされたコードより高速なコードが出力されると聞いたが
CPUごとに最適化できるという意味でな
519:デフォルトの名無しさん
08/09/27 21:45:56
そういう場合もある、程度だろ。
520:デフォルトの名無しさん
08/09/27 21:47:19
まぁなんにせよ初回実行にすこし時間かかります
521:デフォルトの名無しさん
08/09/27 21:50:47
Cとアセンブラの関係とそう変わらないと思う。
どうしても人手の最適が強い部分もあるし、
機械的な最適化の方が強い場面、あるいはそれで十分な場面も多々。
522:デフォルトの名無しさん
08/09/27 21:52:11
できるのとするのは別問題だけどな
523:デフォルトの名無しさん
08/09/27 23:26:34
URLﾘﾝｸ(sts.bkukr.de)
開発環境もポータブル
524:デフォルトの名無しさん
08/09/28 01:31:27
>>511
デリゲートは仮想関数よりもおそいらしい。
どっかの英語のサイトにテスト結果出てた。
普通の関数＞＞＞＞仮想関数＞デリゲートってかんじ
仮想関数とデリゲートは1割ぐらいの差?それほど気にすることじゃないかと。
どっちにしろ普通の関数よりは数倍遅いので其れは柔軟性に必要な代償だと思ってあきらめるがヨロし。
525:デフォルトの名無しさん
08/09/28 05:28:40
フォーム上にtextboxを複数設置してるんですが
それぞれ同じイベントを記述したい時
どのようにすればいいのでしょうか？
private void textBox1_Enter(object sender, EventArgs e)
{
textBox1.BackColor = Color.RED;
}
private void textBox1_Leave(object sender, EventArgs e)
{
textBox1.BackColor = Color.White;
}
フォーム上のテキストボックスをコピペしてもイベント記述は
コピーされないので、困っています。
このような連番のコードを生成するアプリなどあるのでしょうか？
526:デフォルトの名無しさん
08/09/28 06:28:01
全く同じ処理を行うと解釈していいんだろ
ならプロパティ ウィンドウのイベントから全部のTextBoxのEnter/Leaveに
textBox1_Enter/textBox1_Leaveを設定すればいい
527:デフォルトの名無しさん
08/09/28 07:01:41
ありがとう、できました
528:デフォルトの名無しさん
08/09/28 07:58:39
>>524
＞ 普通の関数＞＞＞＞仮想関数＞デリゲートってかんじ
普通の関数が大きく有利になるケースとして、
テストに使用した関数がサイズが小さくJITでインライン化された場合がある。
仮想関数やデリゲートの場合はサイズが小さくてもインライン化されない。
int f(int i) { if (i>=0) return i; else -i; }
という関数を使用した場合普通の関数はJITでインライン化されて非常に有利になる。
最適化をOFFにすればインライン化は抑制されるが、
最適化前提で設計されている.NETのパフォーマンス測定で意味のある行為ではない。
最適化ONのままインライン化を抑制するには無駄なコードを挿入してサイズを増やす必要がある。
テストでは引数i は負になることはないとする。
int f(int i) { if (i>=0) return i;
意味のない大量のコード; -- ただし最適化で捨てられないように
Randomで生成して結果はConsoleに出力するようにするなど工夫が必要
else -i; }
さらにデリゲートに関してはデリゲートの生成を減らす工夫が必要になる。
これらの条件でテストすると普通の関数・仮想関数・デリゲートはほぼ変わらなくなる。
529:デフォルトの名無しさん
08/09/28 08:02:18
君は注意力が足りないようだ
530:デフォルトの名無しさん
08/09/28 11:42:16
リフレクション経由の呼び出しくらいになるとさすがに問題になるだろうけど
インターフェイスとデリゲートなんて普通の使い方ではほとんど意味のない差