Happy boxing! UniRxの前回リリース(UniRx 5.0.0)でパフォーマンス向上を果たしたと書きましたが、まだやり残したことがありました。それがボックス化(boxing)の殺害です。ボックス化は単純に言うと、せっかくの値型が箱に入っちゃってGCゴミが発生してGCがーーー、というもの。避けれるなら避けるべし。あ、ちなみに今回の内容は特に別にUnityに限らないふつーのC#の話です。 それと、というわけかでUniRx 5.1.0リリースしました、アセットストアから落とせます。基本的な内容は以下に解説するボックス化を徹底的に殺害したことによるパフォーマンス向上です。 ボックス化とジェネリクス GCって、別に見えてるnewだけで発生するわけでもありません。見えてるものを警戒するのは大事ですが、見えないものを見てないのは片手落ち感が否めない。そんな見えないものの代表例がボックス化で
最近はUniRxというUnity向けのReactive Extensionsの実装を書いているので、そこにImmutableなCollectionのちょーどよく分かりやすい使い道の実例があるので紹介しようかと思います。Rx自体はImmutable Collections使ってるわけではありませんが、同様の（簡易的）実装を内部で持っています。UniRxも同様に簡易実装を中で持つ形です。 Immutable Collectionsを知らにゃい？詳しくはNET Framework Blog - Immutable collections ready for prime timeを。または、以前に私がセッションで発表した資料もありますので、それも見てください。neue cc - .NETのコレクション概要とImmutable Collectionsについて。1.0リリースからもベータ版のリリースは
この記事はC# Advent Calendar 2013の4日目となります。2012年はMemcachedTranscoder - C#のMemcached用シリアライザライブラリというクソニッチな記事で誰得でした（しかもその後、私自身もMemcached使ってないし）。その前、2011年はModern C# Programming Style Guide、うーん、もう2年前ですかぁ、Modernじゃないですねえ。2011年の時点ではC# 5.0はCTPでしたが、もう2013年、当然のようにC# 5.0 async/awaitを使いまくる時代です。変化は非常に大きくプログラミングスタイルも大きく変わりますが、特にコレクションの、LINQの取り扱いに癖があります。今回は、非同期時代においてLINQをどう使いこなしていくかを見ていきましょう。 Selectは非同期時代のForEach これ超大
実行コンテキスト
久々に、そのうち http://ufcpp.net/study/csharp/ に載せる前提の下書き的なブログ。 概要 .NET Frameworkのスレッドは、実行コンテキスト(execution context: 実行の文脈)というものを持っています。 「文脈」という言葉の意味するところは、「意識することなく皆が共有している情報」ということです。実行コンテキストの場合は、以下のような情報を、スレッドを超えて共有します。 セキュリティ コンテキスト: どういう権限でそのスレッドが動いているかを伝搬して、適切なセキュリティを保つ 論理呼び出しコンテキスト: (実際の呼び出しスタック上の上下関係でな く、)論理的な呼び出し関係での情報共有 情報の共有範囲 実行コンテキストを理解するためには、まず、どういう範囲で情報を共有できればいいのかという話をしましょう。 静的フィールド オブジェクトをま
C# vNext (Roslyn)での async/await の仕様変更
そういえば。昔、こんな話題が。 Async Performance: Understanding the Costs of Async and Await これの「Lift Your Way out of Garbage Collection」の節のあたりに書いてあること。大まかにいうと、 非同期メソッド内のローカル変数は全部フィールドに変更される それが原因で、オブジェクトの寿命が延びてGC性能を多少落とす 将来的に、このC#/VBコンパイラーの挙動は変更するかも という内容。 今がその「将来」か？ということで、Roslynの新しいC#コンパイラーの生成結果をのぞいてみた。 元コード 以下のようなコードを、C# 5.0のコンパイラーと、Roslynの新コンパイラーでビルドして、その結果をIL Spyでのぞいてみる。 static async Task X() { var a = Read
AsEnumerable、といったらLINQのAsEnumerableです。その挙動は、IEnumerable<T>へと型変換をします。それだけ、なので実に影が薄いのですが、それでいて奥深く使いこなしが求められる、はずなのですが陰が薄いので無視されている感がなきにしもあらずなので、しっかりと紹介したいと思います。 AsEnumerableの実装 実装は非常に単純明快で、中身ほとんど空っぽです。 public static IEnumerable<T> AsEnumerable<T>(this IEnumerable<T> source) { return source; } ようするにアップキャストです。どういう時に使えばいいかというと、例えば可変長引数とIEnumerable<T>の両方を受けたいオーバーロードを作る場合。 public void Show(params string[]
Enumに文字列を与えたいというのは少なくなくよくあると思います。例えばFruits.Appleには.ToString()したら「リンゴ」と出て欲しいなー、とか。それならFruits.リンゴと、日本語名つければ？というのはごもっとも。でも、同時に「林檎」とも付けたいなー、とかも思ってしまったりするわけです。しません？Java→C#な人が一番不満に思うのはEnumのようですし（JavaのEnumは高機能！）。 例えばこんな風にかけたらいいな、って。 // こうやって属性定義するだけ！ public enum Color { [Japanese("黒"), Hex("000000"), Rgb(0, 0, 0)] Black, [Japanese("白"), Hex("FFFFFF"), Rgb(255, 255, 255)] White, [Japanese("赤"), Hex("FF000
テストドリブンしてますか？私は勿論してません。え……。別に赤が緑になっても嬉しくないし。コード先でテスト後のほうが書きやすくていいなあ。でもそうなると、テスト書かなくなってしまって、溜まるともっと書かなくなってしまっての悪循環。 そんな普段あまりテスト書かないクソッタレな人間なわけですが(レガシーコード殺害ガイドが泣いている)、普段テスト書かないだけに書こうとすると単純なものですらイライライライラしてしまって大変よくない。しかし、それはそもそもテストツールが悪いんじゃね？という気だってする。言い訳じゃなく、ふつーにバッチイですよ、テストコード。こんなの書くのはそりゃ苦痛ってものです。 Before 例えば、こういうどうでもいいクラスがあったとします。 public class MyClass { public string GetString(string unya) { return (
C#4.0の新機能といったらdynamic。外部から来る型が決まってないデータを取り扱うときは楽かしら。とはいえ、実際に適用出来る範囲はそんなに多くはないようです。例えばXMLをdynamicで扱えたら少し素敵かも、と一瞬思いつつもElementsもDescendantsも出来なくてAttributeの取得出来ないXMLは、実際あんまり便利じゃなかったりする。ただ、ちょうどジャストフィットするものがあります。それは、JSONですよ、JSON。というわけで、dynamicでJSONを扱えるライブラリを書いてみました。ライブラリといっても300行程度のクラス一個です。 CodePlex - DynamicJson 使い方は非常にシンプルで直感的。まずは、文字列JSONの読み込みの例を。DynamicJson.Parseメソッド一発です。 // Parse (from JsonString to
何か盛り沢山になったのでタイトルも盛り沢山にしてみました。SEO(笑) 最近話題のTwitterのChirpUserStreamsを使ってみましょー。ChirpUserStreamsとは、自分のタイムラインのあらゆる情報がストリームAPIによりリアルタイムで取得出来る、というもの。これを扱うには、まずはストリームをIEnumerable化します。そのまま扱うよりも、一度IEnumerable化すると非常に触りやすくなる、というのがLinq時代の鉄則です。C#でのストリームAPIの取得方法は以前にも記事にしましたが、かなり汚かったのでリライト。WebClient愛してる。 public static IEnumerable<XElement> ConnectChirpStream(string username, string password) { const string StreamA
Scala の match を真似て C# で色々書いているわけですが、なんかもう TryParse は Obsolete でいいんじゃ、と思えてきました。 例えばですよ、 public static T MatchInt<T>(this string self, Func<int, T> ifMatch, Func<T> ifNotMatch) { int result; return int.TryParse(self, out result) ? ifMatch(result) : ifNotMatch(); } public static T MatchInt<T>(this string self, Func<int, T> ifMatch) { return MatchInt<T>(self, ifMatch, () => default(T)); } こんな拡張メソッドを用意
先ほどのHow to use SafeHandle in a Resilient Libraryで GC.KeepAliveの話が出ていたので久しぶりに実験と． 関連話題． nyaruru.hatenablog.com d.hatena.ne.jp Re: .NET GC & Interop クイズ 以下のようなコードを実行してみます． using System; using System.Text; using System.Threading; using System.Diagnostics; public class Test { IntPtr MyHandle = IntPtr.Zero; ~Test() { Trace.WriteLine("Finalize; Release Handle"); } public void Hoge() { Trace.WriteLine("G
ヒント ソフトウェアの開発は初めてですか? 作業の 開始 に関するチュートリアルから始めます。 名前付き型を定義せずにメソッドまたはグループ値から複数の値を返す必要がある場合は、タプルが発生します。 別の言語で経験がありますか? C# タプルは、Python または Swift のタプルに似た値型ですが、省略可能な名前付き要素と完全な分解のサポートがあります。 C# 固有のパターンの 分解 セクションと 等値 セクションをスキミングします。 タプルは、名前付き型を定義しなくても、複数の値を単一の軽量構造体にグループ化します。 タプルは、インラインで宣言し、メソッドから戻り、個々の変数に分解できる値型です。 関連する値をすばやく一時的にグループ化する必要がある場合は、タプルを使用します。 たとえば、メソッドから複数の結果を返したり、座標ペアを格納したりする場合です。 次の例では、名前付き要素
本稿は「連載：C# 3.0入門」からスピンオフした（平たくいえばページの都合で掲載されなかった）、「LINQ to XML」に関する紹介である（LINQ自体の基本的な内容については、同連載の第6～8回で解説している）。 C# 3.0入門 第9回では、なぜSQL Serverが使えないかについて述べたが、本稿では、なぜXMLが「使えない」のかという話から始めよう。 XML最大の災厄 XMLという技術を襲った最大の災厄とは、「僕の賢さ」を誇示しようとする「精神の子どもたち」の大挙流入にあるといえる。ここでいう「精神の子どもたち」とは、自分自身を自らの能力以上に優れた存在だと思い込んでいる者たちを示す。別のいい方をすれば、自己評価と社会からの評価にギャップがあるという問題を抱え込んでいる者たちだともいえる。つまり、「僕は本当はもっと優秀なのに、社会はそれを認めてくれない」という屈折を抱えた者たち
世の中，失って初めて気付くことというのがあります．以下はC++でのDrawPrimitiveUPメソッドとMDXでのDrawUserPrimitivesメソッドの宣言の比較です．MDXのDrawUserPrimitivesメソッドはこれ以外にオーバーロードを持ちません．そのためC++では当然のように出来ていたあることがMDXではできなくなっているのですが，お気づきになりましたでしょうか？ // C++ HRESULT DrawPrimitiveUP( D3DPRIMITIVETYPE PrimitiveType, UINT PrimitiveCount, const void *pVertexStreamZeroData, UINT VertexStreamZeroStride ); // C# public void DrawUserPrimitives( PrimitiveType p
分類:[C#] バイト配列どうしの比較をループ以外の方法で出来ますか？ ループして比較してもいいのですが、C#ならではの方法がありそうで いろいろ検索してみたのですが、わかりませんでした。
id:siokoshou:20080130:p2 が面白かったので番外編． IEnumerator<T> 連鎖の動きを spy する． 『IEnumerator<T> を実装していれば必ず IDisposable である理由 - NyaRuRuの日記』で見たように，IEnumerator<T> はステートマシンで説明できます．さしずめ IEnumerator<T> 連鎖は連結ステートマシンということになりますが，この連鎖にモニタリング専用のステートマシンをはさんでみよう，という話です．実際これは拙作 Achiral に既に組み込まれています． 実装としては，ちょうど間に挟まるような何もしない IEnumerator<T> を作って，上流にイベントをフォワードする前後で登録されたデリゲートをコールバックすれば良さそうです．で，問題はこのコールバックの数が 10 ぐらいあるというところで，さて
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
