neue cc - C#におけるTypeをキーにした非ジェネリック関数の最適化法
MicroResolver 2.3.3！というわけで、例によってバージョンがデタラメになるんですが、アップデートしてました。MicroResolverとその解説については以前のブログ記事 MicroResolver - C#最速のDIコンテナライブラリと、最速を支えるメタプログラミングテクニック をどうぞ。そして、オフィシャルな(?)ベンチマーク結果でも、それなりに勝利を収めています。 |Container|Singleton|Transient|Combined|Complex|Property|Generics|IEnumerable| |:------------|------------:|------------:|-----------:|----------:|:------------|----------:|--------------:| |No|61 53|68 62
neue cc - MicroResolver - C#最速のDIコンテナライブラリと、最速を支えるメタプログラミングテクニック
MicroResolver、というDIコンテナを作りました。Microといいつつ、フルフルではないですがそれなりにフルセットな機能もあります。DIの意義とか使い方とかは割とどうでもいい話なので、何をやったら最速にできるのかってところを中心に説明しますので、DIに興味ない人もどうぞ。 GitHub - neuecc/MicroResolver Install-Package MicroResolver 例によってインストールはNuGetからで、.NET 4.6 から .NET Standard 1.4 で使えます。 DIコンテナはIoC Performanceという、存在するDIライブラリは全部突っ込んだ総合ベンチマークがあるので、そこで好成績を出せれば勝ったといえるでしょう。 |Container|Singleton|Transient|Combined|Complex| |:------
MessagePack for C#に見るC#でのバイナリの読み方と最適化法 - Grani Engineering Blog
CTOの河合(@neuecc)です。今回は、2017年3月3日に行った社内での資料を公開します。 Binary Reading in C# from Yoshifumi Kawai グラニでは、そして最新作の黒騎士と白の魔王では、私の開発したMessagePack for C#を全面的に採用しています。採用範囲は、クライアントとサーバー間でのリクエスト/レスポンス通信の他に、サーバーサイドでもRedisへのシリアライズ等に利用しています。 MessagePack for C#は、グラニでの豊富なシリアライザへの知見に基づき開発された、パフォーマンスと機能拡張性の両面において優れた、C#でのバイナリシリアライザではベストといえる仕上がりになっています。そして、既に実プロダクトで動いているので、プロダクション環境で安心して使えるという実績も備えています。 C#においてバイナリの読み書きは基本的
ファイルのダウンロードをレジューム（再開）するには？［C#、VB］ － ＠IT
現在多くのWebサーバでは、ファイルをダウンロードする際にダウンロードの開始位置を指定できるようになっている。この機能を使えば、何らかの理由で中断してしまったファイルのダウンロードを、中断した位置からレジューム（再開、リジューム）することができる。本稿では、そのコーディング方法について解説する。 HttpWebRequest／HttpWebResponseクラスによるダウンロード ここではまず、HttpWebRequest／HttpWebResponseクラス（ともにSystem.Net名前空間）を使用して通常のダウンロード（新規ダウンロード）を行うコードを示す。HttpWebRequest／HttpWebResponseクラスの基本的な使い方については「TIPS：WebRequest／WebResponseクラスでWebページを取得するには？」を参照してほしい。 このDownloadメソ
neue cc - Micro-ORMとC#(とDapperカスタマイズ)
C#に続き、ASP.NET Advent Calendar 2012です。前日は84zumeさんのWebFormっぽいコントロールベスト3でした。私はC#ではMemcachedTranscoder - C#のMemcached用シリアライザライブラリを書きまして、ああ！これこそむしろASP.NETじゃねえか！と悶絶したりなどして、日付逆にすれば良かったよー、困ったよー。しかもあんまし手持ちの札にASP.NETネタがない！というわけで、ASP.NETなのかビミョーですが押し通せば大丈夫だろう、ということでMicro-ORMについて。 Micro-ORM? 最近タイムリーなことに、またORM論争が起こっていて。で、O/R Mapperですが、私としては割と否定派だったりして。C#にはLINQ(to SQL/Entities)があります！はい、色々な言語のORMを見ても、LINQ(to SQL/
リアルタイム通信におけるC# - async-awaitによるサーバーサイドゲームループ - Grani Engineering Blog
CTOの河合(@neuecc)です。Game Tech Session ～AWS Summit Tokyo 2017～にて「『黒騎士と白の魔王』の gRPC による HTTP/2 API/ストリーミング通信の実践」と題して登壇しました。参加いただいたみなさま、ありがとうございます。 4 月にリリースした「黒騎士と白の魔王」では、iOS/Android のモバイルアプリケーションからの全ての通信を gRPC による HTTP/2 で行っています。API リクエストからストリーミングまで、gRPC のあらゆる機能を使って実現した「黒騎士と白の魔王」のアーキテクチャについて、AWS 上でのスケーリングやデプロイを考慮した構成も含めてご紹介します。 「黒騎士と白の魔王」gRPCによるHTTP/2 - API, Streamingの実践 from Yoshifumi Kawai 5/10にUnite
Grani Engineering Blog
こんにちは、@mayukiです。 以前、このブログにてダンプ解析入門 - Visual Studioでの可視化によるC#トラブルシューティングというスタックオーバーフローのような問題を調査する方法について触れましたが、今回はダンプを元にメモリ周りの状態を見ていく方法について調べたので少しまとめてみました。 長い時間実行するようなアプリケーション(アプリケーションサーバーなど)ではメモリの使用状況やメモリリークなどを調査したいというケースがたまにやってきます。そんなときにはプロセスのメモリダンプを取得して解析することで問題の原因がわかりそう…そんなシチュエーションで役立つかもしれません。 お品書き お品書き 前提 メモ: 64bit コンピューターで動作している32bit プロセスのダンプをとる ダンプのみどころ どのツールで解析すれば? Visual Studioを試してみる DebugD
【Unite 2017 Tokyo】「黒騎士と白の魔王」にみるC#で統一したサーバー/クライアント開発と現実的なUniRx使いこなし術
講演者：河合 宜文(株式会社グラニ) こんな人におすすめ ・C#大統一理論について興味のある方 ・UniRxを使ったことがある/使ってみたい方 受講者が得られる知見 ・C#で統一したプロジェクトの作り方 ・UniRxの活用法、メリットとデメリット 講演動画：https://youtu.be/Lvbs22iZFPkRead less
インターフェースを拡張する2つの手段 ― C#への「インターフェースのデフォルト実装」の導入（後編）
破壊的な影響を他に及ぼすことなくインターフェースの機能を拡張するには、デフォルト実装に加えて拡張メソッドも使用できる。今回はこれら2つの方法がなぜ必要なのか、それぞれが得意としている分野について詳しく見る。 ← 前回 連載 INDEX 次回 → デフォルト実装と拡張メソッド C#以外の言語が持つ「インターフェースのデフォルト実装」に類似の機能、例えばJavaのデフォルトメソッドは、「既存のインターフェースに対して、利用側のコードを壊さずに、インターフェース機能を拡張するもの」と説明される。C#で「拡張」というと、すでに拡張メソッドという機能があって、同じ目的のものがすであるのにどうしてデフォルト実装が必要なのかと思うかもしれない。 これら2つの機能は、確かに同じ目的に使える部分もあるが、それぞれにしかできないことも存在している。ひとくちに「インターフェースの機能拡張」といっても、実のところ
デフォルト実装の導入がもたらす影響 ― C#への「インターフェースのデフォルト実装」の導入（中編）
前回は一般論としてのインターフェースとその課題を見た。今回はC#にインターフェースのデフォルト実装を導入すると、どのようなコードが書けるようになるのか、導入するために必要な修正点などについて見ていく。 ← 前回 連載 INDEX 次回 → 前編では、一般的にインターフェースがどのように実装されているかと、インターフェースが抱える問題を説明し、その問題はインターフェースが実装を持てれば解決するという話をした。前置きが長くなったが、今回と次回ではC#における事情について見ていこう。C#でも、インターフェースに実装を持てるようにしたいという動きが出始めている。 要するに、これはインターフェースに対して過剰に掛かっていた制限を緩めるというものであり、技術的な課題はそれほど大きくない。ただし、C#コンパイラーだけでなく、.NETランタイムの修正が必要となる。これは.NET Framework 2.0
インターフェースを「契約」として見たときの問題点 ― C#への「インターフェースのデフォルト実装」の導入（前編）
C#におけるインターフェースとは、ある型が持つべきメソッドを示す「契約」であり、実装は持てない。だが、このことが大きな問題となりつつある。今回から全3回に分けて、C#がこの問題にどう対処しようとしているかを見ていく。 ← 前回 連載 INDEX 次回 → 現在、「C#にインターフェースのデフォルト実装（Javaでいうデフォルトメソッドに相当する機能）を追加しよう」という話がある。C#にこの機能を導入するに当たっては、C#コンパイラーだけではなく、.NETランタイムの修正が必要になる。 この機能の説明に入る前に、前編では、そもそもインターフェースというものが必要とされる理由や、その内部的な仕組みについて説明したい。 インターフェース 多くのプログラミング言語で、クラスとは別にインターフェース（interface： 境界面、接点）*1というものが用意されている。この2つの違いはおおむね、以下の
neue cc - C# 7.0 custom task-like の正しいフレームワークでの利用法
例年、この頃はMVP更新が云々とかなのですが、今年からシステムが変わって更新時期に変動があるんで何もありませんが、一応まだ継続しています。それはともかくとしてVisual Studio 2017が出ました。会社でも全プロジェクトがVS2017に移行完了を果たして、代わり映えしないようで、タプル記法のデコンストラクションとか工夫すると結構便利だな、とか使い始めると色々発見があります。タプル記法やデコンストラクションの工夫に関しては、弊社エンジニアリングブログのC# 7.0 が使えるようになったので ValueTuple を活用してみたをどうぞ。 そんな中で、私がはよ来てくれ……と願っていたC# 7.0の新機能は、task-likeです。Proposal: arbitrary task-like types returned from async methodsで延々と議論されていたようですが
async/await ～非同期なライブラリは楽じゃない～ - 飽きっぽい人のブログ
※個人的な備忘録的なものです。 こっちとかこっちのが良くまとめられています。 ライブラリ制作者向けの内容になっているのでアプリ製作者にはあまり関係がないかもしれません なお、サンプルコードは全てWindowsストアアプリとして実行したものとします デッドロックで泣きを見ないように 下のようなライブラリのコードがあるとします gist11215254 このライブラリのDoAsyncは呼び出され方によってはデッドロックされてしまいます 下のコードがその例になります gist11215568 原因はTaskのWaitメソッドでロックしたスレッドに対して、HeavyWorkAsyncメソッドでワーカースレッドで作業していたTaskが元のUIスレッドに戻ろうとしたためです 図にすると以下のようになります Waitするなと思った方がいらっしゃるかもしれませんが、使用するのは自分ではなく他人のアプリ製作
neue cc - C#(.NET, .NET Core, Unity, Xamarin)用の新しい高速なMessagePack実装
と、いうものを作りました。MessagePackのC#版です。以前に作ったZeroFormatterのコードをベースに、バイナリの読み書きをMsgPackのフォーマットに差し替えたものになります。MsgPackのライブラリはすでにあるじゃん(MsgPack-Cli)！ってことなんですが、パフォーマンスにかなり差があります。 neuecc/MessagePack-CSharp JSON.NET（スタンダードで、豊富なAPIを持ってる）に対するJil（スピード特化、APIは必要十分はあるけれどJSON.NETほどではない）のようなものと思ってください。とはいえ、生のまま使っても問題は出ない（デフォルトのままで最高速が出るようにチューニングしてある）でしょうし、カスタマイズの口自体も十分用意してあります！詳しくは「拡張」の項で説明しますが、既に私自身が他のライブラリへの対応・インメモリデータベー
C# 7.0で知っておくべき10の新機能（後編）
Visual Studio 2017およびVisual Studio Codeで利用可能になったC#言語の新バージョン「7.0」の新機能を、公開されている議論を基に解説。前編として「パフォーマンス向上」と「コード記述の単純化」に関連する6つの新機能を説明する。 ← 前回 連載 INDEX 前編では「データ中心設計」に関連する4つの新機能を説明した。後編である今回は、その続きとして「パフォーマンス向上」と「コード記述の単純化」に関連する6つの新機能を説明する。 本稿ではC# 7.0で追加される機能を10個に分け、さらに「データ中心設計」「パフォーマンス改善」「コードの書きやすさの向上」の3つに分類して紹介する。 【C# 7.0新機能の一覧】 データ中心設計： 1outパラメーター付き引数での変数宣言（Out Var） 2パターンマッチング（Pattern matching） 3タプル（Tup
C# 7.0で知っておくべき10の新機能（前編）
*1 サンプルコードの動作確認はVisual Studio 2017と.NET Core 1.1.1の組み合わせで検証している。また、Linux環境においても、Red Hat Enterprise Linux 7.3に.NET Core 1.1.1を入れた環境で動作確認をしている。正式版で仕様が変更される可能性もあるので、ご了承いただきたい。 前のバージョンであるC# 6.0はコード名“Roslyn”と呼ばれるオープンソースのコンパイラープラットフォームとともにリリースされた一方、言語機能については使い勝手の向上を中心とした控えめな機能追加であった。C# 6.0がリリースされた後、.NET Coreが発表され、C#を含めた.NET RuntimeはLinuxやmacOSでもサポートされるという大きな変化があった。また、コンパイラー、ランタイム、クラスライブラリなどC#および.NET Cor
グラニ x カヤック合同勉強会レポート。ネイティブ開発をテーマに gRPC, Unity, アセット管理, GitLFS について - Grani Engineering Blog
CTOの河合です。 2/24(金)に面白法人カヤックさんと合同で、弊社の休憩/セミナースペースにて勉強会を開催しました！ カヤックさんには以前にもお越しいただいて、その時はVRがテーマだったので、今回はネイティブアプリケーション開発をテーマに、特に弊社では最近gRPCが熱いのでgRPCを切に希望しつつ、お悩みどころでもあるアセット管理などについて、お互いの知見を共有し合いました。 Golang x gRPC の話 カヤック矢吹さんより、GolangとgRPCの話をしていただきました。詳細はカヤックさんのレポート 【旅する勉強会】Grani & カヤックで合同勉強会を開催しました！ へ。 gRPCの採用を検討し最終的には……！理由は非常に納得の行くもので、しっかりした検証と、しかしより良い形を目指して現実的な採用を進めるところは、さすがだと思いました。 NextGen Server/Clie
ラピッドイテレーションを実現するRE ENGINEの設計
【Unite Tokyo 2019】大量のアセットも怖くない！～HTTP/2による高速な通信の実装例～
neue cc - Expression Treeのこね方・入門編 - 動的にデリゲートを生成してリフレクションを高速化
Expression Treeは、IQueryableの中心、Code as Dataなわけですが、それ以外にも用途は色々あります。ただたんに名前を取り出すだけ(考えてみると贅沢な使い方よね)とか、デリゲートを生成したりとか。varはLinqのために導入されたものだからそれ以外に無闇に使うのは良くない(ｷﾘｯ とか言う人は、式木も同じ考えなんですかね、匿名型へも同じ態度で？導入された、そして発展させたのはLinqだとしても、別にそれ以外に使ってもいいんだよって。縛られた考えイクナイ。 というわけで、今更に、初歩からの式木再入門。特に.NET 4から大幅に拡張されて式だけじゃなく文までいけるようになって、何でも表現出来るようになりました。式木の用途は多岐に渡るわけですが、今回はリフレクションの高速化をお題にしたいと思います。プロパティ名の文字列からPropertyInfoを取ってGetVal
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「黒騎士と白の魔王」gRPCによるHTTP/2 - API, Streamingの実践
