目次
1. 背景の紹介
2.3 パフォーマンスを定量的に分析し、最適化の方向性を明確にする
3. パフォーマンス分析への道
3.1 ビジネス プロセスの整理
3.2 定量分析パフォーマンス
四、性能优化之路
4.1 优化代码逻辑" >4.1 优化代码逻辑
4.4 マルチスレッド処理
4.5 遅延計算
4.6 JVM の最適化
5. 概要
ホームページ テクノロジー周辺機器 AI Ctripの移送輸送計画のスプライシングパフォーマンスを最適化する

Ctripの移送輸送計画のスプライシングパフォーマンスを最適化する

Apr 25, 2023 pm 06:31 PM
最適化 プラン

著者について

一言で言えば、Ctripのバックエンド開発マネージャーで、技術アーキテクチャ、パフォーマンスの最適化、輸送計画などの分野に重点を置いています。

1. 背景の紹介

輸送計画と輸送能力リソースの制限により、ユーザーが問い合わせた 2 つの場所の間、または大型休暇中は直接輸送ができない場合があります。 、直接輸送すべて完売しました。ただし、ユーザーは、 電車、飛行機、車、船などの双方向または多方向の乗り継ぎを利用して目的地に到着することができます。また、料金や時間の面で振替輸送の方が有利な場合もあります。たとえば、上海から運城までは、直通列車よりも電車で接続した方が速くて安い場合があります。

Ctripの移送輸送計画のスプライシングパフォーマンスを最適化する

#図 1 Ctrip 列車乗り換え輸送リスト

乗り換え輸送ソリューションを提供する場合、非常に重要です1 つのリンクは、電車、飛行機、車、船などの 2 つ以上の移動をつなぎ合わせて、実現可能な移動計画を作成することです。交通交通の接続における最初の困難は、接続スペースが広大であることです。上海を交通都市として考えるだけでも、1 億近い組み合わせが生成される可能性があります。もう 1 つの困難は、生産ラインのデータが刻々と変化するため、リアルタイム性が要求されることです。電車、飛行機、自動車、船舶に関するデータをクエリします。トランジット トラフィック スプライシングには大量のコンピューティング リソースと IO オーバーヘッドが必要なため、パフォーマンスの最適化が特に重要です。

この記事では、読者に貴重な参考資料とインスピレーションを提供することを目的として、例を組み合わせて、転送トラフィック スプライシングのパフォーマンスを最適化するプロセスで実行される原理、分析、および最適化方法を紹介します。

2. 最適化の原則

パフォーマンスの最適化には、ビジネス ニーズを満たすことを前提として、さまざまなリソースと制約の間でバランスを取り、トレードオフを行う必要があり、いくつかの主要な原則に従う必要があります。不確実性を排除し、問題の最適な解決策に近づきます。具体的には、転送トラフィック スプライシングの最適化プロセスでは、主に次の 3 つの原則に従います。

2.1 パフォーマンスの最適化は目的ではなく手段である

ただし、この記事は、パフォーマンスの最適化ですが、それでも最初に強調する必要があります。最適化のための最適化はしないでください。ビジネス ニーズを満たす方法は数多くありますが、パフォーマンスの最適化はそのうちの 1 つにすぎません。問題が非常に複雑で多くの制限がある場合もありますが、ユーザー エクスペリエンスに大きな影響を与えることなく、制限を緩和するか他のプロセスを採用することでユーザーへの影響を軽減することも、パフォーマンスの問題を解決する良い方法です。ソフトウェア開発では、パフォーマンスを少し犠牲にすることで大幅なコスト削減が達成された例が数多くあります。たとえば、Redis のカーディナリティ統計 (重複の削除) に使用される HyperLogLog アルゴリズムは、わずか 12K のスペースで 264 個のデータをカウントでき、標準誤差は 0.81% です。

問題自体に戻ります。生産ライン データは頻繁にクエリする必要があり、大規模なスプライシング操作が実行されるため、各ユーザーがクエリ時に最新の転送計画をすぐに返す必要がある場合、コストが非常に高くなります。コストを削減するには、応答時間とデータの鮮度の間でバランスを取る必要があります。慎重に検討した結果、分単位のデータの不一致を受け入れることを選択しました。人気のないルートや日付については、初めてクエリを実行するときに適切な移動計画がない可能性があります。この場合は、ユーザーにページを更新するようガイドするだけです。

2.2 不適切な最適化が諸悪の根源である

Donald Knuth 氏は、「Go To ステートメントを使用した構造化プログラミング」で次のように述べています。「プログラマは、考えたり心配したりして多くの時間を無駄にします。クリティカルでないパスのパフォーマンスについて考え、パフォーマンスのこの部分を最適化しようとすると、コード全体のデバッグとメンテナンスに非常に深刻な悪影響が及ぶため、97% の場合、小さな最適化ポイントを忘れるべきです。」つまり、実際のパフォーマンスの問題が発見される前に、コード レベルで過剰かつ大げさな最適化を行うと、パフォーマンスが向上しないだけでなく、エラーの増加につながる可能性があります。ただし、著者は「残りの重要な 3% については、最適化の機会を逃すべきではない」とも強調しました。したがって、常にパフォーマンスの問題に注意を払い、パフォーマンスに影響を与える決定を下さず、必要に応じて適切な最適化を行う必要があります。

2.3 パフォーマンスを定量的に分析し、最適化の方向性を明確にする

前のセクションで説明したように、最適化をより的を絞った最適化を行うために、最適化する前にまずパフォーマンスを定量化し、ボトルネックを特定する必要があります。 。パフォーマンスの定量的な分析には、時間のかかる監視、Profiler パフォーマンス分析ツール、Benchmark ベンチマーク テスト ツールなどを使用して、特に時間がかかる領域や実行頻度が特に高い領域に焦点を当てることができます。アムダールの法則は次のように述べています。「システム内の特定のコンポーネントに対してより高速な実行方法を使用することによって得られるシステム パフォーマンスの向上の程度は、この実行方法が使用される頻度、または合計実行時間の割合に依存します。 」

さらに、パフォーマンスの最適化は長期戦であることに注意することも重要です。ビジネスが発展し続けるにつれて、アーキテクチャとコードは常に変化するため、パフォーマンスを継続的に定量化し、ボトルネックを継続的に分析し、最適化効果を評価することがさらに必要になります。

3. パフォーマンス分析への道

3.1 ビジネス プロセスの整理

パフォーマンス分析の前に、まずビジネス プロセスを整理する必要があります。乗り換え輸送計画の結合には、主に次の 4 つのステップが含まれます:

#a. 南京乗り換え経由で北京から上海などのルート マップを読み込み、ルート自体の情報のみが表示されます。

b. 列車、飛行機、自動車、船舶の出発時刻、到着時刻、出発駅などの生産ライン データを確認します。到着駅、料金と残りのチケット情報など;

c. 実行可能なすべての乗り換え交通手段を組み合わせるために、主に考慮すべきことは、乗り換え時間が短すぎて避けられないことです。転送を完了できないことと同時に、待ち時間が長くなりすぎないようにする必要があります。実現可能なソリューションをつなぎ合わせた後も、合計金額、合計所要時間、乗り換え情報などのビジネス フィールドを改善する必要があります;

d. 一定のルールに従って、から実現可能な転送ソリューションの中から、ユーザーにとって興味深いと思われるいくつかのソリューションが選択されます。

3.2 定量分析パフォーマンス

(1) 時間のかかるモニタリングの増加

時間-消費モニタリングは、各段階の時間のかかる状況をマクロの観点から観察する最も直観的な方法です。ビジネスプロセスの各段階での時間の価値と時間の割合を表示するだけでなく、長期にわたる時間の変化傾向を観察することもできます。

時間のかかる監視では、社内のインジケータ監視およびアラーム システムを使用して、交通輸送ソリューションを接続する主要なプロセスに時間のかかる管理を追加できます。これらのプロセスには、ルート マップのロード、シフト データのクエリとスプライシング、スプライシング プランのフィルタリングと保存などが含まれます。各段階の時間のかかる状況を図 2 に示します。スプライシング (生産ライン データを含む) が時間のかかる部分で最も高い割合を占めていることがわかり、今後の重要な最適化ターゲットとなっています。

Ctripの移送輸送計画のスプライシングパフォーマンスを最適化する

図 2 時間のかかるトランジット トラフィック スプライシングのモニタリング

(2) プロファイラパフォーマンス分析

時間のかかる管理はビジネス コードに侵入し、パフォーマンスに影響を与える可能性があるため、多すぎないようにし、メイン プロセスの監視に適しています。対応する Profiler パフォーマンス分析ツール (Async-profiler など) は、より具体的なコール ツリーと各関数の CPU 使用率を生成できるため、クリティカル パスとパフォーマンスのボトルネックを分析して特定するのに役立ちます。

Ctripの移送輸送計画のスプライシングパフォーマンスを最適化する

#図 3 スプライシング コール ツリーと CPU 比率

図 3 に示すように、スプライシング スキームは(combineTransferLines) が 53.80% を占め、クエリ生産ライン データ (querySegmentCacheable、キャッシュ使用) が 21.45% を占めます。スプライシング スキームでは、スキーム スコアの計算 (computeTripScore、48.22% を占める)、スキーム エンティティの作成 (buildTripBO、4.61% を占める)、およびスプライシングの実現可能性の確認 (checkCombineMatchCondition、0.91% を占める) が 3 つの最大のリンクです。

Ctripの移送輸送計画のスプライシングパフォーマンスを最適化する

#図 4 ソリューション スコアリング コール ツリーと CPU 比率

最も高い割合で計算計画スコア (computeTripScore) の分析を続けると、それは主に、計画を表示するために使用される直接呼び出しを含む、カスタム文字列書式設定関数 (StringUtils.format) に関連していることがわかりました。スコアの詳細)、および getTripId を介した間接的な呼び出し(スキームの ID の生成に使用されます)。カスタマイズされた StringUtils.format の最も高い割合は java/lang/String.replace です。Java 8 のネイティブ文字列置換は正規表現によって実装されており、比較的非効率的です (この問題は Java 9 以降は改善されました)。

// 计算方案评分(computeTripScore) 中调用的StringUtils.format代码示例
StringUtils.format("AAAA-{0},BBBB-{1},CCCC-{2},DDDD-{3},EEEE-{4},FFFF-{5},GGGG-{6},HHHH-{7},IIII-{8},JJJJ-{9}",
aaaa, bbbb, cccc, dddd, eeee, ffff, gggg, hhhh, iiii, jjjj)


// getTripId 中调用StringUtils.format代码示例
StringUtils.format("{0}_{1}_{2}_{3}_{4}_{5}_{6}", aaaa, bbbb, cccc, dddd, eeee, ffff)


// 通过Java replace实现的自定义format函数
public static String format(String template, Object... parameters) {
for (int i = 0; i < parameters.length; i++) {
template = template.replace("{" + i + "}", parameters[i] + "");
}
return template;
}
ログイン後にコピー

(3)Benchmark ベンチマーク テスト

Benchmark ベンチマーク テスト ツールを使用すると、次のことを測定できます。コードのパフォーマンスをより正確に実行時間に反映します。表 1 では、JMH (Java Microbenchmark Harness) を使用して、3 つの文字列フォーマット方法と 1 つの文字列スプライシング方法について時間のかかるテストを実行しています。テスト結果は、Java8 の replace メソッドを使用した文字列フォーマットのパフォーマンスが最も悪いのに対し、Apache の文字列スプライシング関数を使用した場合のパフォーマンスが最も優れていることを示しています。

#表 1 文字列のフォーマットとスプライシングのパフォーマンスの比較

#Apache replace656.537#Java8 には String.format が付属していますApache の StringUtils.join
##実装

1000回の実行にかかる平均時間(us)

##Java8 の replace を使用して実装された StringUtils.format

1988.982

## を使用して実装された StringUtils.format

##1417.474

##116.812

##

四、性能优化之路

通过以上的性能分析,我们发现拼接和查询产线数据是性能瓶颈,字符串格式化影响尤其大。因此,我们将致力于优化这些部分,以提高性能表现。

4.1 优化代码逻辑

优化代码逻辑是最简单且性价比最高的方法,可以是修正有问题的代码或替换为更好的实现。不同的实现,哪怕减上几纳秒,累加起来也是很可观的。借助一些经典算法或数据结构(如快速排序、红黑树等)可以在时间和空间复杂度方面带来显著优势。回到中转交通方案拼接性能优化本身,优化的代码逻辑主要包括:

(1)优化字符串拼接性能

如前面的JMH的结果所示,自定义的字符串格式化函数性能最差,因此作为重点优化目标。优化前后的对比如下所示:

// 优化前,通过Java replace实现的format函数
public static String format(String template, Object... parameters) {
for (int i = 0; i < parameters.length; i++) {
template = template.replace("{" + i + "}", parameters[i] + "");
}
return template;
}
// 优化后,通过Apache replace实现的format函数
public static String format(String template, Object... parameters) {
for (int i = 0; i < parameters.length; i++) {
String temp = new StringBuilder().append('{').append(i).append('}').toString();
template = org.apache.commons.lang3.StringUtils.replace(template, temp, String.valueOf(parameters[i]));
}
return template;
}
ログイン後にコピー

根据JMH的测试结果,即使是优化后的格式化函数,其性能也不是最优的。在不显著影响可读性的前提下,应尽量使用性能更优的StringUtils.join函数。

// 优化前
StringUtils.format("{0}_{1}_{2}_{3}_{4}_{5}_{6}", aaaa, bbbb, cccc, dddd, eeee, ffff)


// 优化后
StringUtils.join("_", aaaa, bbbb, cccc, dddd, eeee, ffff)
ログイン後にコピー

为进一步提升性能,可以在computeTripScore 函数中添加一个开关,仅在调试模式下才展示评分细节,这将确保该字符串格式化函数仅在需要时才被调用。

if (Config.getBoolean("enable.score.detail", false)) {
scoreDetail = StringUtils.format("AAAA-{0},BBBB-{1},CCCC-{2},DDDD-{3},EEEE-{4},FFFF-{5},GGGG-{6},HHHH-{7},IIII-{8},JJJJ-{9}",
aaaa, bbbb, cccc, dddd, eeee, ffff, gggg, hhhh, iiii, jjjj);
}
ログイン後にコピー

优化后的CPU占比如图5所示,此时字符串格式化已经不再是性能瓶颈。

Ctripの移送輸送計画のスプライシングパフォーマンスを最適化する

图5 优化后的拼接调用树和CPU占比

(2)增加索引降低拼接时间复杂度

Ctripの移送輸送計画のスプライシングパフォーマンスを最適化する

图6 增加索引降低拼接时间复杂度

在中转拼接过程中,我们需要将第一程每个班次的到达时间与第二程每个班次的出发时间进行比较,以判断中转时间是否过短或过长。为简化说明,假设换乘时间间隔需要满足大于30分钟且小于6小时。以北京到上海经南京中转的两程火车为例,3月9日北京到南京有66个班次,南京到上海有275个班次,考虑到隔夜车,还需要算上3月10日南京到上海的275个班次,那么最多需要比较36300(66*275*2)次。

为避免频繁比较,参考了MySQL B+树索引的思想,将第二程南京到上海的所有火车班次数据构建成红黑树。其中,树的键为秒级时间戳,例如2023-03-09 11:29出发的G367键为1677247680,值为G367的班次数据。有了索引树,最多只需要10次比较,就可以找到最近的满足最小换乘时间要求的班次。同理,最多需要10次比较,就能找到满足最大换乘时间要求的最晚班次。两者之间的所有班次都满足耗时要求,直接进行拼接即可。改进后最多需要比较1320(66*(10+10))次,约为原来的1/27.5。

(3)使用多路归并求Top-K算法

在筛选方案时,会存在以下场景:有多个中转点,每个中转点都有数百个得分较高的方案(内部已按得分由高到低排序,通过小根堆实现)。最终需要将这些方案合并,并从中筛选出得分最高的K个方案。

最简单的方法是使用快速排序将所有的方案排序,然后选取前K个,时间复杂度约为O(nlog2n)。然而,这并没有利用到每个队列自身有序的特点。通过多路归并算法时间复杂度可降为O(nlog2k),具体步骤为:

a.  从每个队列中拿出第一个元素(得分最高的方案),放入大根堆中;

b. ビッグ ルート ヒープの最上位から最大の要素を取得し、それを結果セットに追加します;

c. キューに要素が残っている場合要素が配置されている場所に次の要素をヒープに追加します;

d. 結果セットに K 個の要素が含まれるか、すべてのキューが空になるまで、手順 2 と 3 を繰り返します。

Ctripの移送輸送計画のスプライシングパフォーマンスを最適化する

#図 7 マルチパス マージ Top-K アルゴリズム

4.2 マルチレベル キャッシュの構築

キャッシュは、データと計算結果をキャッシュできる典型的なスペースフォータイム戦略です。データをキャッシュするとアクセス効率が向上し、結果をキャッシュすると計算の繰り返しが回避されます。キャッシュによってパフォーマンスが向上する一方で、新たな問題も発生します。

  • キャッシュ容量には限界があり、データのロード、更新、無効化、置換の戦略を慎重に検討する必要があります。
  • キャッシュ アーキテクチャの設計: 一般に、メモリ キャッシュ (HashMap、Caffeine など) のパフォーマンスが最も高く、次に Redis などの分散キャッシュが続きます。RocksDB は比較的遅く、と容量の上限はその逆です。慎重に選択して併用する必要があります。
  • キャッシュの不整合の問題を解決する方法と不整合を許容できる期間。

乗り換え輸送ソリューションをつなぎ合わせるプロセスでは、大量の基本データ (駅、管理エリアなど) と膨大な動的データ (シフト データなど) )を使用する必要があります。上記の要素に基づいて、交通輸送スプライシングのビジネス特性と組み合わせて、キャッシュ アーキテクチャは次のように設計されます。

  • 基本データ (駅、行政区域など) .)、データ量が少ないため、変更頻度は低く、全量が HashMap に保存され、全量が定期的に更新されます;
  • # 一部の電車、飛行機、自動車、船舶のスケジュール データは Redis にキャッシュされ、アクセス効率と安定性が向上します。異なる生産ラインで採用されるキャッシュ戦略は若干異なりますが、一般に、スケジュールされた更新と検索トリガーの更新を組み合わせたものです。
  • 1 回のスプライシングで何百もの製品クエリがクエリされる可能性があります。ラインデータの場合、Redis の累積ミリ秒遅延も非常に大きくなります。したがって、パフォーマンスを向上させるために、Redis の上に別のメモリ キャッシュ層を構築することが期待されています。分析の結果、スプライシング プロセスに非常に明らかなホット データが存在し、人気のある日付とルートに関するクエリの割合が非常に高く、その数は比較的限られていることがわかりました。したがって、ホットスポット データのこの部分をメモリ キャッシュに保存し、LFU (最低使用頻度) に置き換えることができ、最終的な生産ライン データのメモリ キャッシュ ヒット率は 45% 以上に達し、これは IO オーバーヘッドのほぼ半分を削減することに相当します。 。
  • 分単位のデータの不一致は許容されるため、接続結果はキャッシュされますが、有効期間内に次のユーザーが同じ出発日の同じルートを問い合わせると、キャッシュされたデータは失われます。直接使用できます。スプライスされた転送スキームのデータは比較的大きいため、スプライシング結果は RocksDB に保存され、パフォーマンスは Redis ほど良くありませんが、単一のクエリへの影響は許容範囲内です。

Ctripの移送輸送計画のスプライシングパフォーマンスを最適化する

#図 8 マルチレベル キャッシュ構造

4.3 前処理

理論的には、2 つの場所間の中継点として任意の都市を選択できますが、実際には、ほとんどの中継都市は高品質のソリューションを接続できません。したがって、いくつかの高品質の転送ポイントは、オフライン前処理によって最初に選別され、それによってソリューションのスペースが数千から数十に削減されます。動的に変化するシフトと比較して、ラインデータは比較的固定されており、1 日 1 回計算できます。さらに、オフライン前処理ではビッグ データ テクノロジを使用して大量のデータを処理でき、時間の消費に比較的影響されません。

4.4 マルチスレッド処理

スプライス処理では、異なる転写点を持つ数十本のラインを処理する必要があります。各ラインのスプライシングは互いに独立しているため、マルチスレッドを使用でき、処理時間を最小限に抑えることができます。ただし、ライン シフトの数とキャッシュ ヒット率の影響により、異なるラインのスプライシング時間を一貫させることは困難です。多くの場合、2 つのスレッドに同じ数のタスクが割り当てられている場合、1 つのスレッドの実行がすぐに終了したとしても、次のステップに進む前に、もう 1 つのスレッドの実行が終了するまで待たなければなりません。この状況を回避するために、ForkJoinPool のワークスチール メカニズムが使用されます。このメカニズムにより、各スレッドが独自のタスクを完了した後、他のスレッドの未完了の作業を確実に共有し、同時実行効率を向上させ、アイドル時間を短縮することができます。

ただし、マルチスレッドは万能ではありません。使用する場合は、次の点に注意する必要があります。

  • サブタスクの実行相互に独立しており、相互に独立している必要があります。依存関係がある場合は、前のタスクが実行されるのを待ってから次のタスクを開始する必要があり、マルチスレッドの意味がなくなります。
  • CPU コアの数によって上限が決まります。同時実行の制限。スレッドが多すぎると、頻繁なコンテキスト切り替えによりパフォーマンスが低下します。スレッド数、CPU 使用率、CPU スロットル時間などの指標には特別な注意を払う必要があります。

4.5 遅延計算

必要な時点まで計算を遅延させることにより、多くの冗長なオーバーヘッドを回避することができます。たとえば、転送計画を結合した後、計画エンティティを構築してビジネス フィールドを改善する必要があり、この部分でもリソースが消費されます。また、すべてのスプライスされたソリューションが選別されるわけではありません。つまり、これらの選別されていないソリューションは引き続きコンピューティング リソースを消費する必要があります。したがって、完全なソリューション エンティティ オブジェクトの構築が遅れます。スプライシング プロセスの数万のソリューションは、最初に軽量の中間オブジェクトとして保存され、完全なソリューション エンティティは、スクリーニング後に数百の中間オブジェクトに対してのみ構築されます。

4.6 JVM の最適化

トランジット トラフィック スプライシング プロジェクトは Java 8 に基づいており、G1 (ガベージ ファースト) ガベージ コレクターを使用し、8C8G マシンにデプロイされます。 G1 は、一時停止時間の要件を可能な限り満たしながら、高いスループットを実現します。システム アーキテクチャ部門によって設定されたデフォルトのパラメータは、ほとんどのシナリオにすでに適しており、通常は特別な最適化を必要としません。

ただし、回線転送方式が多すぎるため、パケットが大きすぎてリージョン サイズ (8G、デフォルトのリージョン サイズは 2M) の半分を超えてしまい、若い世代に直接入力されるべき大きなオブジェクト 古い時代に入ると、この状況を回避するために、リージョン サイズを 16M に変更します。

5. 概要

上記の分析と最適化による、スプライシング時間の消費量の変化を図 9 に示します。

##図 9 転送輸送スキーム スプライシングのパフォーマンス最適化効果Ctripの移送輸送計画のスプライシングパフォーマンスを最適化する

各ビジネスとシナリオには独自の特性がありますが、パフォーマンスの最適化には特定の分析も必要です。ただし、原理は同じなので、この記事で説明されている分析および最適化の方法を引き続き参照できます。この記事のすべての分析および最適化手法の概要を図 10 に示します。

図 10 移送輸送計画のスプライシング最適化の概要Ctripの移送輸送計画のスプライシングパフォーマンスを最適化する

以上がCtripの移送輸送計画のスプライシングパフォーマンスを最適化するの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。

このウェブサイトの声明
この記事の内容はネチズンが自主的に寄稿したものであり、著作権は原著者に帰属します。このサイトは、それに相当する法的責任を負いません。盗作または侵害の疑いのあるコンテンツを見つけた場合は、admin@php.cn までご連絡ください。

ホットAIツール

Undresser.AI Undress

Undresser.AI Undress

リアルなヌード写真を作成する AI 搭載アプリ

AI Clothes Remover

AI Clothes Remover

写真から衣服を削除するオンライン AI ツール。

Undress AI Tool

Undress AI Tool

脱衣画像を無料で

Clothoff.io

Clothoff.io

AI衣類リムーバー

Video Face Swap

Video Face Swap

完全無料の AI 顔交換ツールを使用して、あらゆるビデオの顔を簡単に交換できます。

ホットツール

メモ帳++7.3.1

メモ帳++7.3.1

使いやすく無料のコードエディター

SublimeText3 中国語版

SublimeText3 中国語版

中国語版、とても使いやすい

ゼンドスタジオ 13.0.1

ゼンドスタジオ 13.0.1

強力な PHP 統合開発環境

ドリームウィーバー CS6

ドリームウィーバー CS6

ビジュアル Web 開発ツール

SublimeText3 Mac版

SublimeText3 Mac版

神レベルのコード編集ソフト(SublimeText3)

新しい Win11 コンピューターを受け取った後に設定を最適化し、パフォーマンスを向上させるにはどうすればよいですか? 新しい Win11 コンピューターを受け取った後に設定を最適化し、パフォーマンスを向上させるにはどうすればよいですか? Mar 03, 2024 pm 09:01 PM

新しいコンピュータを受け取った後、パフォーマンスをセットアップして最適化するにはどうすればよいですか? ユーザーは、[プライバシーとセキュリティ] を直接開き、[全般] (広告 ID、ローカル コンテンツ、アプリケーションの起動、推奨事項の設定、生産性向上ツール) をクリックするか、ローカル グループ ポリシーを直接開くことができます。新しい Win11 パソコンを受け取った後に、設定を最適化し、パフォーマンスを向上させる方法について詳しくご紹介します。 新しい Win11 パソコンを受け取った後に、設定を最適化し、パフォーマンスを向上させる方法について詳しくご紹介します。 1 つ: 1. [Win+i] ボタンを押します。 ] キーの組み合わせを押して設定を開き、左側の [プライバシーとセキュリティ] をクリックし、[右側のツールの Windows アクセス許可の下の一般 (広告 ID、ローカル コンテンツ、アプリの起動、設定の提案、生産性)] をクリックします。方法 2

詳細な解釈: なぜ Laravel はカタツムリのように遅いのでしょうか? 詳細な解釈: なぜ Laravel はカタツムリのように遅いのでしょうか? Mar 07, 2024 am 09:54 AM

Laravel は人気のある PHP 開発フレームワークですが、カタツムリのように遅いと批判されることがあります。 Laravel の速度が満足できない原因は一体何でしょうか?この記事では、Laravel がカタツムリのように遅い理由をさまざまな側面から詳細に説明し、読者がこの問題をより深く理解できるように、具体的なコード例と組み合わせて説明します。 1. ORM クエリのパフォーマンスの問題 Laravel では、ORM (オブジェクト リレーショナル マッピング) は非常に強力な機能です。

Laravelのパフォーマンスボトルネックを解読:最適化テクニックを完全公開! Laravelのパフォーマンスボトルネックを解読:最適化テクニックを完全公開! Mar 06, 2024 pm 02:33 PM

Laravelのパフォーマンスボトルネックを解読:最適化テクニックを完全公開! Laravel は人気のある PHP フレームワークとして、開発者に豊富な機能と便利な開発エクスペリエンスを提供します。ただし、プロジェクトのサイズが大きくなり、訪問数が増加すると、パフォーマンスのボトルネックという課題に直面する可能性があります。この記事では、開発者が潜在的なパフォーマンスの問題を発見して解決できるように、Laravel のパフォーマンス最適化テクニックについて詳しく説明します。 1. Eloquent の遅延読み込みを使用したデータベース クエリの最適化 Eloquent を使用してデータベースにクエリを実行する場合は、次のことを避けてください。

C++ プログラムの最適化: 時間の複雑さを軽減する手法 C++ プログラムの最適化: 時間の複雑さを軽減する手法 Jun 01, 2024 am 11:19 AM

時間計算量は、入力のサイズに対するアルゴリズムの実行時間を測定します。 C++ プログラムの時間の複雑さを軽減するためのヒントには、適切なコンテナー (ベクター、リストなど) を選択して、データのストレージと管理を最適化することが含まれます。クイックソートなどの効率的なアルゴリズムを利用して計算時間を短縮します。複数の操作を排除して二重カウントを削減します。条件分岐を使用して、不必要な計算を回避します。二分探索などのより高速なアルゴリズムを使用して線形探索を最適化します。

Golang の GC 最適化戦略に関するディスカッション Golang の GC 最適化戦略に関するディスカッション Mar 06, 2024 pm 02:39 PM

Golang のガベージ コレクション (GC) は、開発者の間で常に話題になっています。高速プログラミング言語として、Golang の組み込みガベージ コレクターはメモリを適切に管理できますが、プログラムのサイズが大きくなるにつれて、パフォーマンスの問題が発生することがあります。この記事では、Golang の GC 最適化戦略を検討し、いくつかの具体的なコード例を示します。 Golang のガベージ コレクション Golang のガベージ コレクターは同時マークスイープ (concurrentmark-s) に基づいています。

Laravel パフォーマンスのボトルネックが明らかに: 最適化ソリューションが明らかに! Laravel パフォーマンスのボトルネックが明らかに: 最適化ソリューションが明らかに! Mar 07, 2024 pm 01:30 PM

Laravel パフォーマンスのボトルネックが明らかに: 最適化ソリューションが明らかに!インターネット技術の発展に伴い、Web サイトやアプリケーションのパフォーマンスの最適化がますます重要になってきています。人気の PHP フレームワークである Laravel は、開発プロセス中にパフォーマンスのボトルネックに直面する可能性があります。この記事では、Laravel アプリケーションが遭遇する可能性のあるパフォーマンスの問題を調査し、開発者がこれらの問題をより適切に解決できるように、いくつかの最適化ソリューションと具体的なコード例を提供します。 1. データベース クエリの最適化 データベース クエリは、Web アプリケーションにおける一般的なパフォーマンスのボトルネックの 1 つです。存在する

WIN7システムのスタートアップ項目を最適化する方法 WIN7システムのスタートアップ項目を最適化する方法 Mar 26, 2024 pm 06:20 PM

1. デスクトップでキーの組み合わせ (win キー + R) を押してファイル名を指定して実行ウィンドウを開き、[regedit] と入力して Enter キーを押して確定します。 2. レジストリ エディターを開いた後、[HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionExplorer] をクリックして展開し、ディレクトリに Serialize 項目があるかどうかを確認します。ない場合は、エクスプローラーを右クリックして新しい項目を作成し、Serialize という名前を付けます。 3. 次に、「シリアル化」をクリックし、右側のペインの空白スペースを右クリックして、新しい DWORD (32) ビット値を作成し、「Star」という名前を付けます。

Vivox100s のパラメーター構成が明らかに: プロセッサーのパフォーマンスを最適化するには? Vivox100s のパラメーター構成が明らかに: プロセッサーのパフォーマンスを最適化するには? Mar 24, 2024 am 10:27 AM

Vivox100s のパラメーター構成が明らかに: プロセッサーのパフォーマンスを最適化するには?テクノロジーが急速に発展する今日、スマートフォンは私たちの日常生活に欠かせないものとなっています。スマートフォンの重要な部分であるプロセッサのパフォーマンスの最適化は、携帯電話のユーザー エクスペリエンスに直接関係します。注目度の高いスマートフォンとして、Vivox100s のパラメータ構成は多くの注目を集めており、特にプロセッサー性能の最適化はユーザーからの注目を集めています。プロセッサは携帯電話の「頭脳」として、携帯電話の動作速度に直接影響します。

See all articles