チャンネルのツリー構造をキャッシュとかに保存する

[kamecha]

チャンネル関連の処理をするたびに、サバから全チャンネル取ってきて諸々してるから、どこかに保存しておく

サバとの整合性はサバから取ってきたものとのチャンネル数から判定したりするとよさげ

[kamecha]

ツリー形式じゃなくて、channelIDとその本体をmapっぽいデータ構造で保持しておけば良さそう ツリー自体は簡単に再現できる事だしね

[kamecha]

traQ本体だと↓こんな感じに実装してるらしい

https://github.com/traPtitech/traQ_S-UI/blob/07d2c543e83dc0f55f2bb2babf63f443ffea16d9/src/store/entities/channels.ts#L19

[kamecha]

deno標準のベンチマークとかdduのprofile機能とかに乗っかって、性能比較もできるようにしたい

[kamecha]

あと当たり前だけど、キャッシュは本体側に置いといて、ddu・ddcに限らず連携するときに早くなってて欲しい

[kamecha]

function s:profile_channel_cache() abort
    let l:startTime = reltime()
    call ddu#get_items(#{ sources: ["channel_rec"] })
    echomsg "Elapsed time: " . reltimestr(reltime(l:startTime)) . " sec"
endfunction

command -nargs=0 TraqChannelCache call s:profile_channel_cache()

↑こんな感じの簡易的な計測　＆ dduのprofile機能を使った場合↓みたくなった

[kamecha]

これちなみにpathを取得する時にパスをconvertしないと短縮される

んでもって、api叩いてチャンネル一覧を取ってくる処理とコンバートする処理とを別で計測した場合↓

dduで取ってくる時は全体のチャンネルと未読チャンネルも一気に取ってきてるから、コンバート処理が２回入って0.5の２倍分くらいは遅くなってる感じ

[kamecha]

コンバート処理をmapキャッシュ使ってやった場合↓↓

いつキャッシュを生成するのか問題とか、そもそものチャンネル取得周りが汚い問題とか色々あるな...

ひとまず以前同様ソースを呼び出すたびにapiは叩いて、そのたびにキャッシュを更新するようにしてみるか...