【VB.NET】LINQ友の会【C#, C♯, C#】

1 名前：デフォルトの名無しさん [2008/02/09(土) 23:51:34 ] VisualStudio2008より追加された便利で強力な機能 　　統合言語クエリ (LINQ : Language Integrated Query) ちょっと使ってみると、意外と難しいし、テクニック的にも奥が深いものです。 関数型言語にしかないような機能ラムダ式(Lambda式)などはオブジェクト指向とは一味違う機能です。 DataBaseの操作にも、Xmlの操作にも、さらにもっと単純な配列なコンテナにさえ機能する 言語共通・高汎用な統合言語クエリを皆で一緒にマターリ勉強しましょう。 質問、便利なマイテクニックの発表、いろいろやっちゃってください。 369 名前：デフォルトの名無しさん mailto:sage [2009/07/08(水) 22:48:23 ] 実際にボトルネックになるような場所でlinq使って叱られるのは当然だが 「なんか遅そうなコード」を見ただけで騒ぐのは 速度至上主義者じゃなくてただの阿呆や 370 名前：デフォルトの名無しさん [2009/07/08(水) 22:49:54 ] 別にそれ自身遅いもんじゃないよ IEnumerableを返すメソッドを手で書いたところでyieldより効率のいいものができるとは考えにくい LINQは素直すぎるだけだ 371 名前：デフォルトの名無しさん mailto:sage [2009/07/08(水) 23:08:48 ] 妄想で語っている人多い気はするね、LINQは初回の実行の時はコンパイルが入るから遅いのは分かるが 一度実行されると、二回目からは高速化する構造になっているしね。 LINQを使わない場合は、平均して中速になる。 ある意味LINQを使わないというのはパフォーマンス的には使いやすいかもしれないが、コーディングの楽さとそこそこのパフォーマンスの両得確保を目指すなら LINQは外せないはず 372 名前：デフォルトの名無しさん mailto:sage [2009/07/08(水) 23:14:43 ] そういうパフォーマンス厨いるけど、実行速度に影響するのはそういう部分じゃなくデータ構造とか効率的なアルゴリズムとか。 LINQでのパフォーマンスの劣化なんてよっぽどの所でないと誤差の範囲。 373 名前：デフォルトの名無しさん mailto:sage [2009/07/08(水) 23:20:03 ] >>371 式木とクエリ式混同してない？ 少なくとも、LINQ to object は動的生成一切ないよ。 foreach でコレクション操作するのに比べて、 静的メソッド呼び出しがちょっと増えて、その分のパフォーマンス落ちる程度。 静的メソッド呼び出しのコストなんてほんとたかが知れてて、 ほんの数％の最適化が必要な超クリティカルな場面以外は気にする必要ない。 374 名前：デフォルトの名無しさん [2009/07/08(水) 23:24:03 ] パフォーマンスについては間違ってる クエリ演算子を繋げることによってネストされた列挙子ができて、列挙自体のコストがちょっとだけ増えるんだよ 375 名前：デフォルトの名無しさん mailto:sage [2009/07/08(水) 23:26:16 ] ああ、そか。 かかるコストは静的メソッド呼び出し分じゃなくて、 仮想メソッド分になるか＜列挙子のネスト。 376 名前：デフォルトの名無しさん mailto:sage [2009/07/08(水) 23:27:55 ] なんか適当な事書かれているような気がするぞ foreachなどでやる場合は、連続したシーケンス操作では計算した値を何処かに確保して また計算してというのが繰り返されているのに対して、クエリをバシバシつなげた場合は、中間データが作られないで処理される。 データ処理が縦に輪切りで処理するか横に輪切りで処理するかが変わる この時決定的な差として、キャッシュの使用量がLINQを使った場合の方が小さくなって結果的に高速化するケースは多い。 オレはこっちの効果を重要視している 377 名前：デフォルトの名無しさん mailto:sage [2009/07/08(水) 23:29:27 ] >キャッシュの使用量 CPUのデータキャッシュの事ね、今のプロセッサではこれが決定的なパフォーマンスを決める 378 名前：デフォルトの名無しさん [2009/07/08(水) 23:36:57 ] LINQ使うときは最後まで列挙や評価を行わせないのが重要 Reverseみたいに、遅延実行の演算子の中にも危ないのがあるので注意 379 名前：デフォルトの名無しさん mailto:sage [2009/07/08(水) 23:37:56 ] yieldは結構便利なことに気付いた。 配列を返させてたところはこれに変えられる。 380 名前：デフォルトの名無しさん mailto:sage [2009/07/08(水) 23:38:06 ] >>378 気にしなくていいと思うけどね、よほどの問題が発生しない限り 381 名前：デフォルトの名無しさん mailto:sage [2009/07/09(木) 00:00:11 ] >>376 実際のところ、測ってみたら速くならなくない？ 1段ラッパーされてる分のペナルティの方が大きくて。 そういうレベルの話よりは、 データ列の処理ってのを1段階抽象化してるから、 LINQ to SQL/Entity みたいなクエリ化もできるし、 PLINQ みたいな並列化もできるしって辺りの もっと抽象度高い話しないと LINQ の価値出ない気も。 382 名前：デフォルトの名無しさん [2009/07/09(木) 00:09:58 ] デリゲート呼び出しのコストがやっぱり大きいんじゃないかな 使い方を変えずにExpressionTreeで一つの大きな列挙子に展開することだって可能なわけで、 そういうところがLINQのポテンシャルなんだろうな 383 名前：デフォルトの名無しさん mailto:sage [2009/07/09(木) 06:19:38 ] Linqというよりデリゲート単独のパフォーマンスを調べたことがある。 サイズの小さい関数の呼び出しはJIT時にインライン化されるが、 デリゲートで呼び出された関数はどんなに小さいものでもインライン化されないようだった。 関数のサイズを大きなものに変えた場合はどちらもほぼ同じ結果になった。 こういう関数があった場合、 int Hoge1(int x) { return x * x; } // こっちはインライン化されるコード インライン化されない関数の作り方としては、xは-10000以下にならないという前提で int Hoge2(int x) {   if (x > -10000) return x * x;   : 実際には実行されない大量のコード } 384 名前：デフォルトの名無しさん mailto:sage [2009/07/09(木) 08:40:19 ] くだらない事やらずに分かりやすく書けやクズ 385 名前：デフォルトの名無しさん [2009/07/09(木) 08:44:04 ] インライン展開はMethodImpl属性で抑制できるぞ 386 名前：383 mailto:sage [2009/07/09(木) 09:18:21 ] すまん、すまん。糞したり飯食ったりしてて続きを書くのを忘れていた。 Enumerable.Whereで条件を指定するところなどLinqの随所にdelegateが使われているわけだ。 その部分をdelegateを使わない形に書き直せば、yieldや拡張メソッドを使っていても、 多重ループで書いたのとそう変わらない結果がでる。 >>382の ＞デリゲート呼び出しのコストがやっぱり大きいんじゃないかな  に同意と言いたかった。 >>385 おおありがとう。インラインの抑制はそのほうがスマートですな。 387 名前：デフォルトの名無しさん mailto:sage [2009/07/09(木) 09:36:21 ] デリゲート呼び出しは通常の関数呼び出しの一割り増しぐらいだと外人の誰かがブログでグラフ付きでかいとったな。 ああいうページいつもどこ行ったか忘れちゃうんだよな･･･ 388 名前：デフォルトの名無しさん [2009/07/09(木) 09:50:59 ] いかにデリゲート呼び出しが速かろうとベタに書くよりはそりゃ遅くなるに決まってる 最適化できなくなるんだから 389 名前：デフォルトの名無しさん mailto:sage [2009/07/09(木) 10:00:52 ] だから遅くても許容範囲なんじゃねーのって話だろ。 そんだけ速いの欲しかったらアセンブラで書いとけよ。 390 名前：デフォルトの名無しさん mailto:sage [2009/07/09(木) 13:22:47 ] それでも・・・僕はLINQを使うんだ！ 391 名前：デフォルトの名無しさん mailto:sage [2009/07/10(金) 01:06:06 ] LINQで要素に連番をふりたいなーと思ったけど 　int index = 0; 　var numbered = 　　　from p in source 　　　let gomi = (++index) 　　　select new { Index = index, Data = p }; と、アホまっしぐらなコードに。 そもそも副作用のある式を入れている時点でマズイとは思うけど これ以外に手はあるんでしょうか？ 392 名前：デフォルトの名無しさん mailto:sage [2009/07/10(金) 01:26:45 ] クエリ式に固執しなければいいんじゃね？ 393 名前：デフォルトの名無しさん mailto:sage [2009/07/10(金) 05:27:16 ] source.Select((Data, i) => new { Index = i + 1, Data }); クエリ構文だとやれることが少ないことに気づくと、だんだメソッド構文ばかり使うようになる 394 名前：デフォルトの名無しさん mailto:sage [2009/07/10(金) 08:19:37 ] トン こんな便利なバージョンがあったとは。 395 名前：デフォルトの名無しさん mailto:sage [2009/07/10(金) 16:21:58 ] C#のLINQは大事なものはほとんど拡張メソッド版になっているよ ムキになってメソッドでやるのもどうかと思うんだが…… VBのXMLリテラルなんぞを見ていると、やっぱ便利だし読みやすいし。 あんまり拡張メソッドに拘って欲しくないんだけどな 396 名前：デフォルトの名無しさん [2009/07/10(金) 22:45:31 ] XMLリテラルってXLINQだろ XLINQ自体は良いものだとは思うけどそんな普及するかどうかもわからない 実験的なものをいきなり言語に組み込むとか 397 名前：デフォルトの名無しさん mailto:sage [2009/07/10(金) 23:20:37 ] 全然違うような 398 名前：デフォルトの名無しさん mailto:sage [2009/07/11(土) 00:00:36 ] VBは使ったことはなかったけど…イコールではないよね。 XMLリテラルはXDocumentやXElementといった LINQ to XMLのクラスを使っているだけで。 って、LINQ to Schema for VB SUGEEEE!!こりゃ楽だわ。C#じゃ使えないのか。 399 名前：デフォルトの名無しさん [2009/07/11(土) 00:09:02 ] だからLINQ to SQLみたいにLINQ to XMLがコケたらどうしようもないだろ 言語仕様レベルで依存してるんだから それくらいしないとVBユーザーは新しいものを使おうとしないだろうとか考えたのかな 400 名前：デフォルトの名無しさん mailto:sage [2009/07/11(土) 00:16:09 ] Linq to Xmlは別にこけるこけないって次元の中身ではないと思うけど。 使ったことないで言ってるでしょ。 401 名前：デフォルトの名無しさん mailto:sage [2009/07/11(土) 01:13:05 ] Linq to XMLはC#では言語構文の拡張は何もやってない。 使ってるのはLinq to Objectの構文だけで、拡張はクラスライブラリだけ。 VBでは言語構文の拡張もやってて、XMLリテラルもその一種。 402 名前：デフォルトの名無しさん mailto:sage [2009/07/15(水) 18:58:43 ] この流れを見て、LINQ to XML触ってみた 書き方はすごく楽だね、こりゃ。 …けど、これってLINQ to XMLで書いてしまうと XMLでデータの不整合や値のレンジ外が見つかった時に XMLのエラー箇所を通知するのが難しい気がする。 例外できないんじゃ実用性って… 403 名前：デフォルトの名無しさん mailto:sage [2009/07/15(水) 22:02:46 ] あるある。 LoadOptions.SetLineInfoを活用しようとして、 ToDictionaryの代わりにToLookup+重複のないことの検査したり、 Count != 1なら自前の例外を投げてから、Single呼んだりする羽目になっている。 404 名前：デフォルトの名無しさん mailto:sage [2009/07/15(水) 22:18:29 ] >>402 スキーマ検証周りならベースにまず XmlReader を使え。 XmlReaderSettings で　XmlSchemaSet が指定できる XLinq 上でもエラー処理したいときは、読み込み周りのオプ ションで XmlReaderSettings の指定とさらに LoadOptions の SetBaseUri や SetLineInfo オプションも忘れずに 405 名前：デフォルトの名無しさん mailto:sage [2009/07/16(木) 00:18:20 ] トン、とても参考になった。SetLineInfoはかなり便利そう >>403 後、フィルタ以外を全部取り除いておいて最低限にしておいて データ一個だけ処理する関数を作ってその中で処理したり 　return from p in hoge.Elements("Hoge") 　　　where (int?)p.Value < 0 　　　select CreateHogeInstance(p); ←この中で整合性チェックして例外を投げる 結構マヌケな作りな気がする。 406 名前：デフォルトの名無しさん mailto:sage [2009/07/16(木) 00:20:28 ] C#なら拡張メソッドがんがん作ってそういうのをチェックしながらのWhereとか例外メッセージつきのSelectとかいろいろ作りゃいいんじゃねーの。 0スタートのindexがくっついてくるSelectWithCountとか自分的に便利。 407 名前：デフォルトの名無しさん mailto:sage [2009/07/16(木) 04:16:14 ] >>406 それって標準のと何が違うの？ msdn.microsoft.com/ja-jp/library/bb534869.aspx 408 名前：デフォルトの名無しさん mailto:sage [2009/07/16(木) 08:01:45 ] index 付きの Select、みんなが意外知らない便利機能だけど、 まったく同じ機能を再発明しちゃった人までいるのか。 409 名前：406 mailto:sage [2009/07/16(木) 08:29:31 ] ・・・(´・ω・｀) WhereWithCountとか色々作ったのに･･･ 410 名前：デフォルトの名無しさん mailto:sage [2009/07/16(木) 10:22:56 ] 引数なしのAny()とかも影薄いよな Count() > 0とかやっちゃってる人も多そう 411 名前：デフォルトの名無しさん mailto:sage [2009/07/16(木) 14:36:23 ] 作ってみると意外と簡単でつい自前で作ってしまう。 デバッグ用に意外と役に立ったり。 public static void ToVoid<T>(this IEnumerable<T> src) {   foreach (var s in src) {}; } public static void ToVoid<T>(this IEnumerable<T> src, Action<T> act) {  foreach (var s in src) act(s); } 412 名前：デフォルトの名無しさん mailto:sage [2009/07/16(木) 14:51:15 ] 手軽に作れるのが魅力の1つだよな 413 名前：407 mailto:sage [2009/07/16(木) 17:27:01 ] >>410 > Count() > 0とかやっちゃってる人 ……、ごめんなさい。私です。 >>411 それ、自分はC++から来たからForEachって名前にしたい、特に後者。 414 名前：デフォルトの名無しさん mailto:sage [2009/07/16(木) 17:42:57 ] List<T>との整合性を考えても、ForEachの方がしっくりくるな 415 名前：デフォルトの名無しさん mailto:sage [2009/07/16(木) 19:36:16 ] >>413 Count使うと最後まで読まないといけないからパフォーマンスが悪いはず Anyは一件あるかないかだから速いはず 416 名前：デフォルトの名無しさん mailto:sage [2009/07/29(水) 01:05:17 ] ttp://www.infoq.com/jp/news/2009/07/Reactive-Framework-LINQ-Events 417 名前：デフォルトの名無しさん mailto:sage [2009/09/12(土) 18:41:51 ] ﾇﾙﾎﾟ 418 名前：デフォルトの名無しさん mailto:sage [2009/09/12(土) 19:39:22 ] LINQと例外処理ってどうやって組み合わせている？ IEnumerableを参照する全ての場所で例外が起こるかもしれない、 となると例外安全の確保をしなきゃならない範囲が滅茶苦茶広くなるし、 任意のtry-catchで捕まえることもできない。 自分は「LINQ中に例外を外に投げる処理は入れるな」で対応している。 419 名前：デフォルトの名無しさん mailto:sage [2009/09/12(土) 23:31:27 ] LINQからIEnum処理するところすべてtry-catch(´・ω・｀) 420 名前：デフォルトの名無しさん mailto:sage [2009/09/13(日) 00:16:47 ] それは、不毛過ぎるw 421 名前：デフォルトの名無しさん mailto:sage [2009/09/14(月) 20:55:08 ] 配列の要素を２個ずつ処理したいときにはどうすればいいでしょうか？ ruby の each_slice みたいなのがやりたいのですが。 422 名前：デフォルトの名無しさん mailto:sage [2009/09/14(月) 21:12:59 ] static IEnumerable<IEnumerable<TSource>> Slice<TSource>(this IEnumerable<TSource> source, int n) { 　　var buf = new TSource[n]; 　　int i = 0; 　　foreach (var item in source) { buf[i++] = item; if (i == n) { i = 0; yield return buf; } } 　　if (i != 0) { yield return buf.Take(i); } } 423 名前：421 mailto:sage [2009/09/15(火) 15:00:48 ] >>422 ありがとう。 424 名前：デフォルトの名無しさん mailto:sage [2009/09/15(火) 21:59:43 ] LINQらしさを追求してみた source.Select((x, i) => new { Key = i / n, Element = x }) 　　　　.GroupBy(x => x.Key, x => x.Element) 　　　　.Cast<IEnumerable<TSource>>(); 425 名前：デフォルトの名無しさん mailto:sage [2009/09/16(水) 06:48:18 ] まあどっちでもいいんじゃない？ 拡張メソッドはガンガン使うべきなのかは迷うところ。 426 名前：デフォルトの名無しさん mailto:sage [2009/09/16(水) 21:47:09 ] イベントをLINQっぽく操れるリアクティブフレームワークってのを最近知ってからというもの .NET4.0とラブプラスのことで頭が一杯です。 427 名前：422 mailto:sage [2009/09/17(木) 11:04:44 ] 今更だけど>>422は使われ方によっては問題があるかも static IEnumerable<IEnumerable<TSource>> Slice<TSource>(this IEnumerable<TSource> source, int n)　{ var buf = source.ToArray(); for (int i = 0; i < buf.Length; i += n)　yield return buf.Skip(i).Take(n); } メモリは食うけどこっちの方が確実 428 名前：デフォルトの名無しさん mailto:sage [2009/09/17(木) 11:22:16 ] いやSkipやTake使ったらbufの意味がないな こんなの用意して代わりに使うか static IEnumerable<TSource> SkipTake<TSource>(TSource[] source, int skip, int take) { for (int i = 0; i < take; i++) yield return source[i + skip]; } 429 名前：デフォルトの名無しさん mailto:sage [2009/09/17(木) 17:10:47 ] 次はforをForEach()にするんですね 430 名前：デフォルトの名無しさん mailto:sage [2009/09/17(木) 19:00:29 ] 427のはあまり良くないと思う。 422のyield return bufを yield return buf.ToArray()に変えるだけで良いかと。 あと最後はbuf.Take(i)でいいかな。 431 名前：デフォルトの名無しさん mailto:sage [2009/09/17(木) 19:07:12 ] sourceがIList<TSource>を実装しているか否かで場合分けするのが効率的か 432 名前：デフォルトの名無しさん mailto:sage [2009/09/27(日) 19:20:03 ] 条件に合うものと合わないものを分けるために、 bar = foo.Select(i=>Baz(i) ); foo = foo.Select(i=>!Baz(i)); みたいに２回Selectしてるんですが、 １回で済む方法ないですか？ 433 名前：432 mailto:sage [2009/09/27(日) 19:23:15 ] 間違いました。 where を２回です。 434 名前：デフォルトの名無しさん mailto:sage [2009/09/27(日) 19:24:56 ] 欲しいのはどっちなの？ 両方ほしいなら2回しないといけないと思うけど。 やりたいことが見えない。 435 名前：デフォルトの名無しさん mailto:sage [2009/09/27(日) 19:37:47 ] 両方欲しい場合、自前でループを廻せばワンパスで振り分けできるけど、 Linqで同じようにできないか、っていう質問だろうね。 気持ちは分かるけど多分できないんだろうなあ。 Linqの想定用途はあくまで選択や射影の簡略化だろうし、振り分け処理で 無理矢理Linq使う必要無いんじゃない？と思う。foreachでいいじゃん。 436 名前：デフォルトの名無しさん mailto:sage [2009/09/27(日) 19:49:14 ] そういうメソッドを自作すればいい。 IEnumerable<T>受け取ってTuple<IEnumerable<T>, IEnumearble<T>>でもを返すようにしてさ。 437 名前：432 mailto:sage [2009/09/27(日) 19:58:37 ] 優先度のある条件を集合に適用する処理を 以下のように書きました。 foreach(var 条件 in 条件リスト){ var マッチしたもの = 集合.Where(条件) 集合 = 集合.Where(!条件) 　（マッチしたものに対する処理） } というループを書いていたのですが、 ruby の partition メソッドみたいなのがあれば 一回ですむじゃん。 と思ったのですが、ヘルプをみてもわからず、 ググってもわからず、なので質問させていただきました。 処理が重いので１パスにしたいというわけではないので、 ２回 Where するままにしておきます。 レスありがとうございました。 438 名前：デフォルトの名無しさん mailto:sage [2009/09/27(日) 20:11:24 ] やりたいのはこういうこと？ Func<int, bool> cond = x => x % 2 == 0; var q = from x in new[] { 1, 2, 3, 4, 5, 6, 7, 8, 9, } let b = cond(x) group x by b; var even = q.First(x => x.Key); var odd = q.First(x => !x.Key); 439 名前：デフォルトの名無しさん mailto:sage [2009/09/27(日) 21:04:04 ] だね。 ruby の partition メソッドはズバりGroupBy。 ToLookupはその即時評価版。 440 名前：デフォルトの名無しさん mailto:sage [2009/09/29(火) 02:41:06 ] ToLookupなんてあるんだな。 おもしろそうだからこれを使ってFizzBuzzをといてみた。 var nums = Enumerable.Range(1, 100); var fizzbuzz = nums.ToLookup(num => (num % 15 == 0 ? "fizzBuzz" : (num % 5 == 0 ? "Buzz" : (num % 3 == 0 ? "fizz" : "Other"))), arg => arg); foreach (var group in fizzbuzz) { Console.WriteLine("*****" + group.Key + "*****"); foreach (var num in group) Console.WriteLine(num.ToString()); } 441 名前：デフォルトの名無しさん [2009/10/10(土) 19:43:10 ] プログラミングC#でLINQの項目をちょっと読んでみたが、 C#のコード中に普通にselectとかfromとか書くのは違和感あるなぁ。 C#の予約語になってんのかね？ 442 名前：デフォルトの名無しさん mailto:sage [2009/10/10(土) 19:44:40 ] >>441 文脈キーワード 443 名前：デフォルトの名無しさん mailto:sage [2009/10/13(火) 12:02:58 ] LINQって別に最適プランとか計算しないんでしょ? ほんのちょっと前までデータベースからデータを「SELECT * FROM TABLE」で持ってきて コード内でデータの取捨を行うなんて、やっちゃだめの最右翼だったのに、すんげえ 富豪的プログラミングだなあ…。 444 名前：デフォルトの名無しさん mailto:sage [2009/10/13(火) 12:30:06 ] WHERE句はあるには有るけど 内部で式評価を最適化しているわけではない 445 名前：デフォルトの名無しさん mailto:sage [2009/10/13(火) 12:54:50 ] Linq to Objectにはプランナはない。命令の順番で処理される。 Linq to SQLやEntity Frameworkの場合はDBMSのSQLに翻訳されるから、 DBMSのプランナが機能する。 446 名前：デフォルトの名無しさん mailto:sage [2009/10/13(火) 19:08:08 ] LINQ to SQLって、要するに式ツリーからSQLを生成するORMという理解でOK？ 447 名前：デフォルトの名無しさん mailto:sage [2009/10/13(火) 19:17:58 ] LINQ to SQLの中身がわかってない奴が多いのな。 とりあえずDataContext.Logで吐かれるSQLを確認するところから はじめたらどうだ？ 448 名前：デフォルトの名無しさん mailto:sage [2009/10/13(火) 20:29:13 ] ですな。 >>443 のような酷い勘違いは初めて見たけど。 449 名前：デフォルトの名無しさん mailto:sage [2009/10/13(火) 20:40:37 ] LINQ to Objectsを最適化するとしたら，DynamicMethodでインライン展開かなあ コード生成のコストが高いからあんまり意味なさそう 450 名前：デフォルトの名無しさん mailto:sage [2009/10/13(火) 21:37:17 ] >>446 Whereの条件とかは式ツリーだけど、Where自体は式ツリーでない >>447-448 まあ、LINQ to SQLで生成されるSQLも大概だがな 作成したクエリ(IQueryable)をそのまま変換してるからサブクエリが深すぎて何が何やら 451 名前：デフォルトの名無しさん mailto:sage [2009/10/13(火) 23:25:35 ] >>446 そう。ただ実行の度に発行される。ToList()すりゃ1回ですむけども。 452 名前：デフォルトの名無しさん mailto:sage [2009/10/26(月) 18:34:12 ] 　　　　　　　　　　　 ／） 　　　　　　　　　　／／／）　　 ノ´⌒｀ヽ 　　　　　　　　 ／,.=゛''"／γ⌒´　　 　　 ＼ 　　／　　　　 i f　,.r='"-‐'つ　""´ ⌒＼　　） 　/　　　　　 /　　　_,.-‐'~　　＼　　／　 ｉ　）　　　こまけぇことはいいんだよ！！ 　　　／　 　,i　　　,二ニ⊃　(･ ）｀ ´( ･） i,/ 　　/　 　　ノ　　　 il゛フｌ 　　　（__人_）.　 | 　　　　　,イ「ト、　　,!,!　＼　　　｀ー' 　 / 　　　　/　iトヾヽ_/ィ"　　 ｀７　　　　 　〈 453 名前：デフォルトの名無しさん mailto:sage [2009/11/07(土) 12:28:38 ] データは作成する回数よりも参照される回数の方が多いわけで、 キャッシュがないから遅延されても重くなるだけじゃないか？ 結局はToList()しまくるハメになっている気がする。 454 名前：デフォルトの名無しさん mailto:sage [2009/11/07(土) 13:04:29 ] SQLはちゃらっと書く分には楽だな。 最適化とか考えてくとだんだんめんどくさくなりそうだけど。 つーかいい加減データアクセスモデルはナイスな奴一つにまとめてくれ。 Oslo？ 455 名前：デフォルトの名無しさん [2009/11/07(土) 19:58:09 ] 確かにMSは昔からデータアクセスの新方式を乱発しすぎなんだよな。 456 名前：デフォルトの名無しさん mailto:sage [2009/11/09(月) 14:02:34 ] 遅延評価も即時評価も都合に合わせて選択できるってことで 今のモデルで悪くないと思うがな。 そもそも本当にチューニングが必要な場所ならLinqは使わないだろ。 性能云々うるさいやつ向けに..Optimize()あたりを追加してみるか？ 457 名前：デフォルトの名無しさん [2009/11/09(月) 17:37:01 ] 手段がいろいろ用意されて軽く破綻してるC++の二の舞ですね パラダイムを混ぜこぜにするとよく起こる 458 名前：デフォルトの名無しさん mailto:sage [2009/11/10(火) 17:39:44 ] 結局のところ記述性と性能はトレードオフなんだよ 459 名前：デフォルトの名無しさん mailto:sage [2009/11/13(金) 00:55:32 ] え、いや、Linq の遅延評価は記述性って言うか スケーラビリティ？だべ。要素数がドカーンって なっても使えるという意味での。 460 名前：デフォルトの名無しさん mailto:sage [2009/11/15(日) 02:05:16 ] SelectMany の戻り値に一つだけ要素を足したいです。 今は、 var list = new List<T>(); list.Add(item); list.AddRange(foo.SelectMany(i => bar(i))); のように書いてますが、なんか 冗長な気がします。 １個要素を足すためだけに List のインスタンスを 生成するのは無駄な気がするんですが、 避ける方法ないでしょうか？ 461 名前：460 mailto:sage [2009/11/15(日) 02:16:19 ] すまん、Concat を見つけた。 foo.SelectMany(i=>bar(i)).Concat(new[]{ item }); と書けた。 でも、配列生成してんのが無駄な気がするが、 回避する方法ないよね？ ( new List<T>(){ item } とかは無しでw) 462 名前：デフォルトの名無しさん mailto:sage [2009/11/15(日) 03:02:15 ] () => { yield return item; } 463 名前：デフォルトの名無しさん mailto:sage [2009/11/15(日) 10:18:15 ] ラムダ内をイテレーターブロックにはできないよ。 やるなら、拡張メソッド追加して、 public static IEnumerable<T> Concat(this T x, IEnumerable<T> list) { yield return x; foreach(var i in list) yield return i; } public static IEnumerable<T> Concat(this IEnumerable<T> list, T x) { foreach(var i in list) yield return i; yield return x; } 464 名前：デフォルトの名無しさん mailto:sage [2009/11/15(日) 11:46:45 ] >>461 Enumerable.Repeat(item, 1) で回避。 465 名前：デフォルトの名無しさん [2009/11/15(日) 12:01:40 ] 拡張メソッドにT使えたっけ？ 466 名前：デフォルトの名無しさん [2009/11/15(日) 12:17:35 ] Concat<T>が正解ね 467 名前：デフォルトの名無しさん mailto:sage [2009/11/15(日) 16:28:58 ] >>464 それたぶん配列作った方が効率的 Rangeで作られるイテレータよりも配列のイテレータの方がずっと速いはず 468 名前：467 mailto:sage [2009/11/15(日) 16:30:40 ] 間違えたRepeatか 469 名前：デフォルトの名無しさん mailto:sage [2009/12/11(金) 00:11:22 ] Linq to Object で List 内のデータを取り出した時に、そのデータを変更することはできるのでしょうか？ Linq to Object では、抽出するだけなのでしょうか？

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef