タグ付けされた質問 「performance」

プログラマの皆さん、 車両の通行をシミュレートするソフトウェアを開発しています。「割り当て」と呼ばれるプロセスの一部は、ルートへの車両の割り当てに関係しており、ある種の最短経路探索アルゴリズムを使用する必要があります。 伝統的に、人々はダイクストラでこれを行っており、特定の科学文献は、おそらくグラフの性質のために、A *や他の代替案は大幅な改善をもたらさないことを示しているようです。 したがって、ダイクストラも使用しています。小さな問題が発生しました。交通リンク（交差点間の道路のスパン）をエッジとして扱い、交差点をノードとして扱う場合、古典的な単方向グラフを取得できません。交差点に近づくと、頻繁に方向転換できるかどうかは従来のグラフでは、ノードから任意のエッジを取得できますが、 この問題は、リンクと交差のペア（「ラス」と呼ばれます）をノードとして表すことで簡単に解決できました。後続の「ラス」または選択したポイントに到達するにはリンクをたどる必要があるため、エッジがこのトラバーサルとして定義され、典型的なグラフが得られます。 次に、結果は単純なテーブルN x Nに格納されます。ここで、Nは「ラス」の数です。 これは（避けられない？）欠点です。シミュレーションの一般的なネットワークに2000の交差点がある場合、約6000リンク、つまりN = 3Vになります。明らかに、交差（V）で数えると、O（log（3V）*（3V + E））になります。 3（または9）は一定の要素であると主張するかもしれませんが、実際の観点からは、処理速度がかなり遅くなり、ストレージスペースが3V x 3Vに増加します。 これを再構成してパフォーマンスを向上させる方法を誰かが知っていますか？必ずしも別のアルゴリズムである必要はありません。おそらく、他の方法でグラフに合うようにデータ構造を再形成しますか？

8 algorithms  performance  data-structures  simulation 

バックグラウンド 私は最近、.NETスタックを使用するポジションの厳しい技術面接に耐える過程にあります。その中には、このような愚かな質問や、より有効な質問が含まれています。最近、有効な問題に遭遇しましたが、確認するにはここのコミュニティに確認したいと思います。 面接官から、テキストドキュメント内の単語の頻度を数え、結果をランク付けする方法を尋ねられたとき、私は ストリームオブジェクトを使用して、テキストファイルを文字列としてメモリに配置します。 句読点を無視しながら、文字列をスペース上の配列に分割します。 配列とに対してLINQを使用.GroupBy()し.Count()、次にOrderBy()カウントと言います。 私は2つの理由でこの答えを間違えました： テキストファイル全体をメモリにストリーミングすると、障害が発生する可能性があります。それが完全な百科事典だったらどうでしょうか？代わりに、一度に1つのブロックをストリーミングして、ハッシュテーブルの作成を開始します。 LINQは高すぎるため、必要な処理サイクルが多すぎます。代わりにハッシュテーブルを作成する必要があり、反復ごとに、存在しない場合にのみハッシュテーブルに単語を追加してから、カウントをインクリメントしました。 最初の理由は、まあ、理にかなっているようです。しかし、2番目は私にもっと休止を与えます。LINQのセールスポイントの1つは、ハッシュテーブルのような下位レベルの操作を単純に抽象化することですが、ベールの下では、同じ実装です。 質問 抽象化されたメソッドを呼び出すためのいくつかの追加の処理サイクルを除いて、LINQは、特定のデータ反復タスクを実行するために、低レベルのタスク（ハッシュテーブルの作成など）よりもはるかに多くの処理サイクルを必要としますか？

8 algorithms  .net  performance  linq 

Big-Oでこの投稿を読ん でいます。次のコードはO（n ^ 2）であると表示されています。 bool ContainsDuplicates(String[] strings) { for(int i = 0; i < strings.Length; i++) { for(int j = 0; j < strings.Length; j++) { if(i == j) // Don't compare with self { continue; } if(strings[i] == strings[j]) { return true; } } } return false; } しかし、なぜか分かりません。 …

8 algorithms  performance  complexity  big-o 

通常、マイクロ最適化は次の説明では価値がないと見なされます。プログラムを1パーセント未満高速化する可能性がありますが、その小さなブーストを気にする人はいません。 さらに、1秒間に1000回起動し、非常に高速に終了するイベントハンドラが存在する可能性があります。それがどれほど速いかは誰も気にしません-それがすでに「観察できるほど速い」ので、それを速くすることは注目に値しません。 ただし、モバイルデバイスではエネルギー消費が重要な要素です。同じイベントハンドラーを10％速く実行するように最適化すると、消費されるエネルギーが少なくなり、バッテリー寿命が長くなり、デバイスの動作時間が長くなります。 モバイルデバイスに関する後者の判断はどの程度正確ですか？それを確認または反証する実際の例はありますか？

8 performance  optimization  mobile 

さて、私は今日これについて考えていました、そして私はそれについて完全に主観的でバイアスのある意見を求めるようになりました。逆説的に、これにもかかわらず、私はそれが炎戦の飼料でもないと思います。完全に文明化された会話の余地はあると思います-Vim対Emacsはほとんどありません。 私は多くの並行処理の抽象化、特にスレッドの上に構築されたものを使用しました。メッセージパッシング、デフォルトでは不変、デフォルトではスレッドローカル、その他のいずれでも、それらの間には大きな傾向があります。 トレンドは、データ共有を暗黙的ではなく明示的にすることで、スレッドの考え方を逆転させているというものです。つまり、特に指定しない限り、すべてのデータは共有されません。これは、Javaなどの言語で見られる従来のスレッド化とは逆です。（ただし、Javaは独自の高レベルの同時実行抽象化をサポートしていることを知っています。）たとえば、メッセージを明示的に渡します。どの変数がスレッドローカルであるかを明示的に指定します。変更可能な変数を明示的に指定します。これらは、いくつかの言語で見られるほんの一例です。 この並行性の簡単なスタイルは現代のコンセプトだと思いました。間違えた。最近fork（）やpipe（）のようなUNIXのおもちゃをいじり始めましたが、UNIXの開始以来、簡単で明示的な並行処理メカニズムが存在していることを知ってショックを受けました。 70年代のC + UNIXが同時実行性を多くの最新のトレンディなスレッド化メカニズムよりもはるかに簡単にすることを実現することには、少し奇妙な点があります。 だから、ここで私が疑問に思っているのは...これらの現代のスレッド抽象化は、すべての明示性とデフォルトで共有されない特性を備えたスレッド上でUNIXスタイルのプロセスを単にエミュレートしようとしているのでしょうか？STMのようないくつかのメカニズムがDBスタイルのトランザクションのようなものを提供することは確かですが、それは本当に並行性のための現代的で革新的なソリューションですが、ほとんどの場合、UNIXプログラマーが昔行っていたことを行う新しい方法のように見えます。 言うまでもなく、私はUNIXのファンではなく、想像力を伸ばしているわけでもありません。プロセスは多くのプラットフォームで初期化するためにスレッドよりもはるかに遅いことを認識していますが、これは概念的に述べています。

8 performance  multithreading  concurrency 

私は質問を読み、それを解決する方法についての入力を探しています。 数値はランダムに生成され、（拡張）配列に格納されます。中央値をどのように追跡しますか？ 問題を解決できる2つのデータ構造があります。1つはバランスのとれたバイナリツリーで、もう1つは2つのヒープで、要素の最大の半分と最小の半分を追跡します。これら2つのソリューションの実行時間はと同じだと思いますO(n lg n)が、自分の判断はわかりません。 中央値を追跡する最良の方法は何ですか？ 私の試み： この質問では、中央値を追跡するにはヒープが最良の方法だと思います。大きなヒープと小さなヒープの2つのヒープがあり、これらは順次である必要はありません。まず、配列の要素の平均値を計算します。要素が平均値より小さい場合は、numを小さなヒープに入れます。逆に、numを大きなヒープに入れました。大きいヒープの数が小さいヒープの数と等しい場合、小さいヒープの最大のヒープと大きいヒープの最小のヒープが中央値になります。2つのヒープのサイズが異なる場合は、大きいサイズのヒープからルート要素をポップし、小さいサイズのヒープのルートにプッシュします。大きなヒープの場合、ルート要素は最小の要素であり、小さなヒープの場合、ルート要素は最大の要素です。このようにして、2つのヒープのサイズが同じであるか、デジタル差がある場合、 このソリューションの実行時間はO（m * n）であると思います。mは、アンバランスヒープを調整する時間を意味します。 これは中央値を追跡する最良の方法ですか？

8 algorithms  performance  math 

休業。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善してみませんか？この投稿を編集して、事実と引用で回答できるように質問を更新してください。 6年前休業。 イベントソーシングは、速度、パフォーマンスのスケーラビリティ、透過的な永続性、透過的なライブミラーリングを提供する手段としてLMAXによって普及しました。イベントソーシングと改名される前は、このタイプのアーキテクチャパターンはシステム普及率と呼ばれていましたが、LMAXチームが公開されるまでは、このパターンに慣れていませんでした。 このパターンは多数の本番システムで証明されていますか？したがって、保守的な個人でさえ、このパターンを受け入れる力があると感じる必要がありますか、それともイベントソーシング/システムの普及は、恐れを知らない人のために残されたエキゾチックなパターンですか？

8 java  architecture  performance  management  event-sourcing 

与えられた文字と長さに基づいてすべての反復的な順列を生成するJavaプログラムを作成しました。 Eclipseでコードを実行すると、わずか15秒で1,000,000の順列を持つファイルが生成されます。それでも、「java permutation」を使用してコマンドプロンプトで同じマシンでプログラムを実行すると、同じ1M順列を生成するのに1分35秒かかります。 どうしてこれなの？とにかく私は日食を使わずにこのタイプのパフォーマンスを得ることができますか？ 編集：Java VisualVMの結果を追加 www.craftboom.co.uk/jvm.png-日食で実行すると、CPU使用率が高くなります。シェルo_OでCPUとメモリの両方の使用量が0に低下することがある EDIT2：画面への印刷に問題があることがわかりました。元の投稿では触れていませんでしたが、プログラムは各順列をコンソールに出力します。コメント化してファイルに保存しました。シェルと日食の両方で同じくらい高速に実行されます :-) 返信ありがとうございます。

8 java  performance