{開発}{開発記録}{一段落}{}{知番}{デライト}{希哲16年6月30日}{希哲16年6月18日}{壊衝}{OFFSET}(211)

{希哲16年6月30日の開発 K#F85E/E74C-A106}

デライト高速化における KNEST 隠し実装一段落した。18日作業方針検討のみで20日から,休日除いてちょうど10日間での達成だった。出振るい済み

全体としては大成功だった。

必要以上に固め過ぎるのも良くないため,隠し化現時点最低限必要範囲留めたが,期待以上安定性期待通り高速化得られた次の施策出来たので,まだまだ高速化出来るKNEST 隠しDex匹敵するデライト武器になるだろう。

交度整理しっかり進めたこともあり最初の輪数取得改良想定以上に長引いたものの,ここで KNEST 隠し共通の問題ほとんど解決したため,自我隠し輪郭隠し半日ほどで終わった。この交度整理収穫として大きかった輪郭操作系の kn の外充て函数整備したことで関連交度一気に整理された

影響範囲確率的に大きな問題はないだろうと見て排他制御甘い部分あえて残して出振るい急いだが,出振るい直後壊衝多発して少し焦ったすぐに論軸的問題気付修正し,その後むしろ想定以上に安定して動いている。この判断結果として正解だった。

輪数取得改良

輪数隠しに関しては,第二次知番改良中に固まった輪数取得改良」として,輪数取得仕組み全体的に改良した

これまでデルンではいちいち厳密な輪数表示をしていたが,これが大きな低速化要因になっていた。デライト以前まで,count()遅さ対する認識が甘かったデライト以後そもそも出場における件数計算原理的に遅いもの,と気付いてページ付けOFFSET上限設けるなどの対策はしていた希哲13年10月14日の開発記録が,輪数一筋縄ではいかない部分があり放置してきた

厳密な同期必要性隠し効率から,次のように整理することにした。

読み込み中...
{進捗記録}{進捗}{b_bg_his}{_dg}{_dg_oln}{希哲14年8月12日の開発}{ON 句}{ネステッドループ結合}{マージ結合}{20倍}(35)

{希哲14年8月12日17歩 K#F85E/5B28-F0B2}

前後景一覧整備,装体書整理ページ付け自輪郭検索

途中で終了。

低速求頼については,ほぼ _dg_dg_oln結合部分で生じていることを突き止めた。

どうしても気になりあれこれ試行錯誤していると,WHERE 句 に書いていたフラグb_delb_bg_his)の条件count() 内に移した(OR NULL 付き)だけで,明らかに速くなることに気付いた。その差はおよそ20倍

いまいち理由把握しきれていないが,EXPLAIN ANALYZE では,WHERE 句にフラグ列を含めるとマージ結合になりかなり無駄な処理が入っていることが分かるが,count() に含めるとネステッドループ結合になり無駄なく索引が使われている。

WHERE 句のフラグに索引を張っても ON 句に移しても変化が無かった。

もう少ししっかり理解して最適化しなければならないが,良い一時凌ぎにはなるだろう。

ここで,昨年,_dg_olnn_fgn_bg を加えていたことを思い出した。すっかり忘れていた。これも活かせば,速度上の問題はほぼ解消しそうだ。

{進捗記録}{進捗}{希哲13年12月15日の開発}{SQL::fn_T}{COUNT()}{SQL::cnt()}{希哲13年12月15日の進捗時限}{希哲13年12月15日の進捗}{希哲13年12月15日}{SQL 類型}(14)
{COUNT()}

{}