sklab @ ウィキ

キャッシュ

2015-08-23T21:40:28+09:00

#contents ** Generic Type Caching generic & static なクラスをキャッシュとして使うことである。~ 型引数が key、static メンバが value に相当する。~ 静的コンストラクタは、クラスの呼び出し時に1回だけ実行され、スレッドセーフである。~ そして、型引数はコンパイル時に解決されるため、Dictionary などの動的な key ルックアップと比べて、圧倒的に早い。 new { 変数名 }.GetType().GetProperties()[0].Nameで変数名を文字列で取得できる。 private static class GenericCache { public static string GetName(this T source) where T : class { return GenericCache.Name; } static GenericCache() { var properties = typeof(T).GetProperties(); Name = properties[0].Name; } public static readonly string Name; } **MyCacheを作ってみる。 -Dictionaryでkeyにオブジェクトなんかを入れている場合、そのkeyがGC対象になったときにvalueもGC対象にする -変数（フィールドやらローカル変数やら）に格納されている参照のことを「強い参照」と言う。~ 「アクセス可能なオブジェクト」とは、強い参照が存在するオブジェクトのことを言う。~ ただし、その強い参照を所持しているオブジェクトもアクセス可能なオブジェクトである必要がある。~ つまり、強い参照を所持しているオブジェクトを辿って行くとアクセス不可能なオブジェクトに辿り着く場合、~ それらは全てアクセス不可能なオブジェクトである。~ また、実際にアク

スレッド

2015-08-20T21:22:10+09:00

#contents **専用スレッドを使用して非同期の計算量依存の処理を実行する -下記に当てはまる場合は専用スレッドを使用したほうがよい --通常とは異なる優先度で動作するスレッドが必要な場合 --スレッドをフォアグラウンドスレッドとして動作させ、そのスレッドのタスクが完了するまでアプリケーションが終了しない --計算量依存のタスクに非常に長い時間がかかる --スレッドを開始した後で、完了する前にThreadのAbortメソッドを呼び出してスレッドを中止する場合 ***専用スレッド作成 Thread dedicatedThread = new Thread(MethodName);~ dedicatedThread.Start(5); **CLRスレッドプール -CLRごとに１つのスレッドプールがある -スレッドプールはすべてのアプリケーションドメイン間で共有 -単一のプロセス内に複数のCLRがロードされている場合は複数のスレッドプールがある -アイドル状態が続くと、スレッドは自動で起動し、処理を実行し終了する --リソースの問題が出そうだが、アプリケーションがそれほど多くの処理を実行していないことを意味しているため問題ない **単純な計算量依存の処理を実行するスレッドプールのキューにタスクを投入するには、ThreadPoolクラスが利用される -QueueUserWorkItemメソッド --QueueUserWorkItem(WaitCallback callback, Object state) --callbackに実際の処理を記述 **memo -最適なスレッド数はCPUの数と同じ。コンテキストスイッチが発生しないため

Effective C

2015-08-19T22:14:54+09:00

#contents **#1.publicなデータメンバではなく、プロパティを使う -publicならばプロパティを使う -全てのデータメンバは例外なくprivateにするべき -インデクサを使用することでdictionary機能を付加することもできる **#2.constよりもreadonlyを使う -パフォーマンスはconstが優位 -constはリビルドしないと値が更新されない **#3.キャスト時にはisあるいはas演算子を使う -as演算子は型変換を行うが、is演算子は型変換が可能かを返すのみ -as演算子とキャストではas演算子の方が高速に動作する -as演算子は参照型のみに有効(値型はnullを取れない) **#4.#ifの代わりにConditional属性を使用する -実行の有無が切り替えられる。 -例：[Conditional("DEBUG")] -voidのみ適用可能 -#if/#endifよりも最適なコードが記述される **#5.ToString()を常に実装する -独自にクラスを定義する場合、そのクラスを利用する全てのコードに意味のあるToString()を実装するべき -複雑な情報を持つ型を作成する場合にはIFormattable.ToString()

スレッド処理

2015-08-11T18:52:58+09:00

#contents **CLRスレッドプール -CLRごとに１つのスレッドプールがある -スレッドプールはすべてのアプリケーションドメイン間で共有 -単一のプロセス内に複数のCLRがロードされている場合は複数のスレッドプールがある -アイドル状態が続くと、スレッドは自動で起動し、処理を実行し終了する --リソースの問題が出そうだが、アプリケーションがそれほど多くの処理を実行していないことを意味しているため問題ない **単純な計算量依存の処理を実行するスレッドプールのキューにタスクを投入するには、ThreadPoolクラスが利用される -QueueUserWorkItemメソッド --QueueUserWorkItem(WaitCallback callback, Object state) --callbackに実際の処理を記述

スレッドの基礎

2015-08-20T21:20:25+09:00

アプリケーションドメインとCLRのホスティング

2015-08-10T11:55:40+09:00

-memo --MSCorEE.dllはどのCLRバージョンを生成するか決める際に際に使用される。 --マーシャリングとは、プロセスのオブジェクトを境界越しに処理できるようにする過程のことです。例えば、Word のオブジェクトを Excel のスプレッドシート上に貼り付ける場合、プロセスの境界を越える必要があります。 --すべてのプロセスは、アプリケーションドメインを持ち、さらに新規のアプリケーションドメインを作成することができます。アプリケーションドメインは、独立して開始、停止させることができます。これを利用して、例えば、別のプログラマが書いたライブラリを実行する場合、２番目のアプリケーションドメインに隔離することで、このライブラリがクラッシュしても、プログラム全体を停止させてしまわないようにすることができます。

マネージヒープとガベージコレクション

2015-08-10T11:17:20+09:00

#contents *マネージヒープの基本 -CLRではすべてのリソースはマネージヒープから割り当てられる。 -ヒープ内で次にオブジェクトを割り当てる場所を示すポインター(NextObjPtr)を管理する -CLRはプロセスのアドレス空間が満杯になるまで領域を割り当てる(32bitでは1.5GB) **マネージヒープからリソースを割り当てる -型のフィールドに必要なバイト数を計算する。 -オブジェクトのオーバヘッドフィールドに必要なバイト数を計算する(32bitでは8byte,64bitでは16byte)。 -使用可能かどうかをCLRにて検査し、可能であればNextObjPtrにオブジェクトを格納する。ない場合はGCを呼ぶ --マネージヒープではオブジェクトの割り当てはポインターへの加算のみであり、非常に高速 **GCのアルゴリズム -オブジェクトの生存期間を管理するために参照カウントを行う(参照カウントALG=循環参照時に問題あり) -参照追跡型のアルゴリズムを使用する。 -GCを開始すると、CLRはプロセス内のすべてのスレッドを停止する --ステートが変更されるのを防ぐためである -マーキングフェーズを開始する --参照型の変数root(クラスの静的インスタンスフィールド、メソッドの引数などの総称) --rootがnullであるならばそのルートを無視し、次を検査する -コンパクションフェーズ --どのオブジェクトが生き残るか、削除するかを前フェーズで完了している --すべての生き残りオブジェクトをコンパクションしてメモリ上で連続するようにする =参照の局所性が上がる --このフェーズではオブジェクトのポインタが変わるため、アプリケーションがオブジェクトを参照できなくなる。 ---参照先のオブジェクトがメモリ内で移動したバイト数を各ルートから引き算している -重要 --静的フィールドは永久にまたは型がロードアプリケーションドメインがアンロードされるまで参照先のオブジェクトを保持する。 --メモリリークが発生する主な原因はコレクションオブジェクトを参照する静的フィールドであり、コレクションオブジェクトに項目を追加したままになっていることである。 -世代別ガーベジコレクション *memo -

ショートコードプログラミング

2015-08-18T21:47:16+09:00

#contents *TryParseを使用する string src = "123"; ~ int result; ~ Console.WriteLine(int.TryParse(src,out result) ? result : -1); ~ 処理の重い例外を避けることができる。定石は if(int.Tryparse(xxx, out yyy)){処理} *null合体演算子 string a = "We are the Hello World!!"; ~ Console.WriteLine(a ?? "(null)"); ~ nullポインタ参照を劇的に減らす事ができる。~ WindowsフォームアプリケーションのNullチェックにも適用可能。~ string str = (string)listBox1.SelectedItem ?? "not selected"; *引数にラムダ式大事 *名前を指定したメソッド呼出 dynamicが一番 *列挙可能なオブジェクトを作ってみる class Sample : IEnumerable{ ~ public IEnumerator GetEnumerator(){ ~ for(int i=0,i<10; i++) yield return i;~ } IEnumerator IEnumerator.GetEnumerator(){~ return GetEnumerator(); ~ }~ yield returnが本当に便利。foreachが使える。 *連番の生成 Enumerable.Range(1,10) *配列まとめ var found = a.FindAll((c)=>c>0); // 0よりも大きい数値を返す ~ foreach(var n in a.Where((c)=> c > 0) //ループなしで塊をさばく1 ~ a.Where((c)=>c>0).Count() //ループなしで塊をさばく2 ~ foreach(var n in a.SkipWhile(c,i)=>i <= 0)) // 先頭行を飛ばす。C

.NETアプリケーション最適化技法

2015-05-07T22:43:25+09:00

#contents *型の内部 -1000万個の点の配列をメモリに格納することを考える。 --参照型 ---1000万個の点の配列に含まれるのは同じ数の参照(約40MB) ---オブジェクト自体の使用量も含むとおよそ160MBにもなる。 ---ヒープに格納されるとメモリ内で連続する保証はなく、アプリケーションの実行時間が遅くなる。 --値型 ---無駄なく1000万個の点が収容され、合計40MBとなる。メモリ密度が大幅に異なる。 **.NETの参照型クラス、デリゲート、インターフェイス、配列、string **ストレージ、割り当て、解放 -参照型は常にマネージヒープ領域に割り当てられる(ポインタ操作)。 -ポインタ操作によりパフォーマンスが著しく低下する。

オライリー

2015-04-07T23:08:58+09:00

-FindAllやFindAllIndexなどは便利 -stringのTrimなどはコピーを返している -匿名型であっても裏ではクラスが作成されている -一度作成された文字列は不変