- - PR -
c# 高速化についての質問
| 投稿者 | 投稿内容 | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2005-10-18 17:21
こんにちは、以後のことも考え高速化をしようと思っているのですが、どうも高速化についての文献が調べられず困ってしまったので質問をさせていただきました。
基本的に高速化については ・アルゴリズム ・ファイルサイズ などが関係あることは承知しています、それとフォーム上でコントロールを大量に配置するとインスタンス化に時間がかかるということも承知しています。 また、描画時にシャドウビットマップ（セカンダリサーフェイス）を使用するべきということや、Application.DoEvents()の使用意味、Refresh()の意味なども承知している（つもりです） ですが、細かい部分が良く分かりません、以下のようなことです ・struct（class）の入れ子 コードを読みやすくするために設定情報などを入れ子状態のstructで表現したとします、たとえば struct Setting { struct Window { public Point Location; public Size Size; } struct Tab { public Point Location; public Size Size; public string Name; } public Window window; public Tab tab; } （例が悪いですね…入れ子にする意味がわからない…） このような場合、入れ子にせずに記述した場合と入れ子にして記述した場合では実行速度は変わるのでしょうか？またその速度はコード理解のしやすさとはかりにかけたときにどちら側に傾くでしょうか（これには個人差はありますが… ・staticの扱い フォームを多重起動する場合、フォーム上の処理で使うサブルーチン等をstaticとして宣言して使用したほうが早いのか？変わらないのか？遅いのか？（フォームをインスタンス化する場合にstatic宣言のメソッド・プロパティ・変数などは関係するのか？というかインスタンス化する場合に関係する要素はなんだ？？？？）ということです。たとえばフォーム上で16進数文字列を10進数int型に変換する ReHex(string str)というメソッドがあるとします、これを static として宣言して Form1.ReHex(str); とするほうが良いのか this.ReHex(str) とするほうが良いのかまたは変わらないのかということです。 ・new で作るがclassではなくstructのもの たしかPoint Size Rectangleなどはstructだったと思います、それらをnew Point(0,0)として呼び出しても良いのかそれともPointZeroZero = new Point(0,0);としてからPointZeroZeroを使用するべきなのか（明らかに毎回インスタンス化するのはよくないとは思いますが、新たに変数を宣言してそこに保存しておくとメモリを消費する・加えコードが分かりづらくなるというデメリットもあるわけで、それらを考えたときにnew Point(0,0)と行っても問題ないのかということです） ・usingで宣言すると速度に関係があるのか？ そのまんまです、使わないものを残しておくとコードに関係があるのか？やVBのwith(だったけか？)のように使うと多少コードの速度があがるのか？ということです。 そのほか高速化に関係のある情報をいただけるとうれしいです。読みやすいコードと高速なコードの秤のこともありますが、ここでは単に『高速化とその度合い』について教えていただきたいです（秤にかけるのは個人の差があるので） まことに身勝手な質問ですが、コードの高速化についての記事がどうも見当たらないので質問させていただきました。 よろしくお願いします。 | ||||||||||||||||
|
投稿日時: 2005-10-18 17:55
MSDNの記事をどうぞ
Writing Faster Managed Code: Know What Things Cost http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/fastmanagedcode.asp Writing High-Performance Managed Applications : A Primer http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/highperfmanagedapps.asp Performance Considerations for Run-Time Technologies in the .NET Framework http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/dotnetperftechs.asp Performance Tips and Tricks in .NET Applications http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/dotnetperftips.asp C# In-Depth: Harness the Features of C# to Power Your Scientific Computing Projects -- MSDN Magazine, March 2004 http://msdn.microsoft.com/msdnmag/issues/04/03/ScientificC/ _________________ IEEE-CSDP 2004-2007 | ||||||||||||||||
|
投稿日時: 2005-10-18 18:04
コードの高速化に関係しそうなキーワードを
思いつくまま挙げてみました。 StringBuilder BeginUpdate is より as でキャスト Cashe HaseTable Unsafe MSILコードを解析 Structのガイドライン ガベージ コレクタ エラーチェック より 例外処理 Reflectionの高度な使用(ディスク出力だったかな） Threadやその他非同期処理 このへんにも目を通しておくと、設計指針が得られるかも知れません。 ・型の使用方法のガイドライン ・パフォーマンスを考慮したエンジニアリングの基礎 #個人的には、コードの実行速度より総合的な快適さ重視です。 
#項目をいくつか追加 [ メッセージ編集済み 編集者: 葉瀬崎浩樹 編集日時 2005-10-18 18:22 ] | ||||||||||||||||
|
投稿日時: 2005-10-18 18:26
＞葉瀬崎浩樹さま
情報提供ありがとうございます、日本語でもちゃんと資料あったんですね（orz これから読みに行きたいと思います。 ＞ｉＳｔａｔｉｏｎさま .NET Generalをサラ読みしましたが.NET全般についてですね、細かな高速化に役立ちそうです、ありがとうございます。 | ||||||||||||||||
|
投稿日時: 2005-10-18 19:26
前回の記事はリンク先をじっくり読む前に書いたので訂正
日本語の高速化に関する細かい資料はないですね（汗。 リンク先見てみましたが ビットごとの OR 演算は高度な概念なので、単純なタスクでは実行しないでください。 言語コンパイラは、const フィールドの値を呼び出しコードに直接格納します。 程度しか高速化に関係がありそうなデータ見つかりませんでした、僕の探し方が悪いのかなorzちなみに現在英文と格闘中です…orz（MSDNの文献firefoxじゃ折り返しされないからマイクロソフト嫌いです…） isよりasでキャスト（無知なものでよくわかりません…汗 int i = (int)o;が（明示的）キャストではないのですか？ MSILコードを解析（しただけじゃ早くならないですよね…汗 エラーチェック より 例外処理（これはエラーチェックを多数かけるよりも例外処理で飛ばしてやるほうが早いという意味でしょうか？ＶＢ時代に防ぐことが可能なエラーは防ぐほうが良いとどこかで聞いた気がするのですが、c#ではエラーチェックを行うよりもエラーを発生させて拾うほうが良いのでしょうか？ について詳しく教えていただけないでしょうか？ いろいろとお手数かけますすいません。 | ||||||||||||||||
|
投稿日時: 2005-10-18 20:37
高速化って、どの程度のことを想定しているんでしょうか？
はっきりいって姑息な高速化手法は、大変な割りに効果が小さいです。 ※姑息って書き方は語弊があるかな、つまり、話に出てきたような細かい部分です。 たとえば現在WindowsFormで画面のあるアプリケーションの動作が遅い、 というような現象が出ている場合、細かい話での高速化を行ったって、 まず体感できるような効果はありません（絶対とは言いませんが）。 つまり、今までに出てきた方法によって改善される可能性があると思われる、 レベルのオーダがあまりにも違いすぎます。 たとえば、UI絡みで遅いときに、isをasに置き換えてもほとんど意味はありません。 一般化しすぎた高速化の話は困難だと思います。 | ||||||||||||||||
|
投稿日時: 2005-10-18 20:39
高パフォーマンス ASP.NET アプリケーションの開発
http://www.microsoft.com/japan/msdn/library/ja/cpguide/html/cpconDevelopingHigh-PerformanceASPNETApplications.asp # Windowsアプリにも有効なTipsがあります。 .NET アプリケーションのパフォーマンスとスケーラビリティの向上 http://www.microsoft.com/japan/msdn/enterprise/pag/scalenet-intro.asp | ||||||||||||||||
|
投稿日時: 2005-10-18 21:05
コンパイル時の最適化を行っていなかった場合には影響するかもしれない。でも最適化した場合には、影響は排除されるはず。 素直にコンパイラが解釈すると、Settings.Tab.Locationと言うのは、（Settingのアドレス） + (TABへのOFFSET値) + (Location へのOFFSET値)となるはず。後半二つのOFFSET値の計算結果は変わらないので、最適化時に事前演算されて変わらなくなるはず。
static に宣言した方が高速に動作するはずです。通常のメンバ関数はクラスのインスタンスを識別するための情報を何らかの形で（おろらく暗黙の引数として）渡しているはずです。staticに宣言すれば、その分確実に早くなるはずです。 ・・・けどね、関数に渡されるパラメタが一つ減った程度の速度の改善は、よほど繰り返し呼び出すのでない限り、誤差と大差ありません。下手に使えばコードを分かりにくくするだけですので、高速化を目的としてstaticにする事は無いでしょう。
C#言語仕様の「クラスと構造体の違い」を参照してください。 クラスでは単純に代入した場合に参照が渡されるのに対して、構造体では値のコピーが渡されます。代入のたびにインスタンスが複製されるので、通常は構造体の方が遅くなります。
分かりません。でも影響しない予感がします。 昔「一瞬と刹那の考察」と言う掲示板がありまして、それこそ１クロック単位での高速化についての解説がありました。もちろんアセンブラですけどね。とても楽しく読ませていただいたのを覚えています。でも、本当に高速化を目指すのなら、structとか、staticとか、usingとか、そんなミクロな視点でほんの僅かな高速化を重ねる前にやることがあるでしょう。アルゴリズムを見直すとか、データ構造（キャッシュヒット率に大きく影響する）を見直すとか、処理の並列化（ハイパースレッディングやマルチコアのCPUでは大きく影響する）を試みるとか、そもそも使用する言語の選択を見直すとか。 | ||||||||||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。