{開発}{開発記録}{KNEST 隠し実装}{KNEST 隠し}{浮上式隠し}{初出振るい}{デライト高速化}{希哲15年4月12日10歩}{隠し化}{自我の隠し化}...=}(34)

{希哲15年4月20日の開発 K#F85E/E74C-F806}

主にデライト高速化KNEST 隠し実装自我の隠し化

糸間共有であることもあり KNEST 隠し慎重実装を進めてきたが,ようやく初出振るい出来た(9歩)。これが最初の KNEST 隠し実装ということになる。適用は最小限範囲に留めた。今のところ上手く動いている。

出場負荷軽減には期待出来るものの,体感表示速度改善としてはまだ微妙なところか……と思ったが,あちこちページ移動を繰り返していると確かに速くなっていることが分かる。

試金石のような役割を期待していた自我の隠し化だが,まずは成功と言っていいだろう。これで他の隠し化も一気に進めやすくなったのは大きな進展だ。


4月12日10歩から考え始めた浮上式隠し実装方針もまとまってきた。

重複検出には p_勘体利用することにした。

{進捗記録}{手定め}{KNEST 隠し実装}{KNEST 隠し}{希哲15年4月20日の開発}{初出振るい}{KNEST::cch_ego_T}{応答時間短縮}{不安定化}{希哲15年4月20日の進捗時限}...=}(32)

{希哲15年4月20日9歩 K#F85E/E74C-751D}

デライト高速化KNEST 隠し実装自我の隠し化

途中で終了。

KNEST::cch_ego_T がある程度の形になったため,手定め初出振るい。まずは輪郭一覧部分にのみ適用

KNEST 隠し糸間共有なこともあり不安定化懸念実装慎重にせざるをえなかったが,今のところ上手く動いている。

ばらつきはあるものの,0.1秒から0.5秒ほどの応答時間短縮が見られた。

体感的には微妙なところだが,出場負荷軽減効果は大きいだろう。

何より,これで KNEST 隠しの実装を進めやすくなったのは大きな進展だった。

=}
{開発}{開発記録}{握接}{kitetsu.com}{KNEST 隠し実装}{きっぱり}{ゆるく}{輪郭 URL}{希哲15年4月17日}{デライト高速化}...=}(26)

{希哲15年4月17日の開発 K#F85E/E74C-B74C}

主にデライト高速化KNEST 隠し実装自我の隠し化


昔の輪郭 URL から正常に握接出来ない問題に気付き修正8歩)したのをきっかけに,これまでの URL変遷について振り返り,最近よく考えるようになっていたドメイン整理についても少し進展した。

kitetu.comkitetsu.com絞り込んで他はきっぱり捨てるべきかどうかで迷いがあったが,絞り込みつつ,他のドメイン余裕があれば程度にゆるく保有だけしておく,という考え方が良いかもしれない。

{隠し}{進捗記録}{握接}{デライト}{KNEST 隠し}{浮上式隠し}{希哲15年4月12日の開発}{実出与え}{隠し管理}{握接頻度}...=}(59)

{希哲15年4月12日10歩 K#F85E/E74C-C35E}

散歩中KNEST 隠し設計方針について進展があったため,軽くまとめ。

KNEST 隠し実装2月9日再開してからまた停滞していた。デルンデライト最適見通しの良い隠し実装について少し迷いがあった。

先月中旬頃だったか,自我情報の取得が削りやすいことに気付き,自我の隠し化から着手しようとは思っていた。比較的少数で全ての輪郭に関わり,出与え量は少なく更新頻度も低いため,最も隠しとして利用しやすい。

難しいのは輪郭ページ単位での隠し化で,とにかく膨大握接分散するため,自我と異なり工夫が必要になる。

少なくとも,握接頻度で隠し全体を一定の大きさに保っておかないと破綻するのは目に見えている。

ここで,握接のたびに浮上して,一定数を越えると沈んでいるものから破棄されていくようなリスト連想配列とは別に持っておくことを考えた。効率的理積み(特に重複の削除)は別に考える必要があるが,これなら隠し管理をだいぶ単純化出来る。

各隠しには隠し化した時点の時印を持たせておくことも考えていたが,これは応付にしておく。サービスの性質上,実出与え反映時間差を持たせたくない場面も多く,一律に持たせても無駄な出与えになる可能性が高い。

{自我の隠し化}

{}