8000 jsmnを使って起動時のタイムラインJSONをtoot単位で処理して表示する by tsutsui · Pull Request #83 · taka-tuos/nanotodon · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

jsmnを使って起動時のタイムラインJSONをtoot単位で処理して表示する #83

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

tsutsui
Copy link
Contributor
@tsutsui tsutsui commented Dec 9, 2024

このままマージされることは想定していないコンセプトレベルの差分です。

課題

LUNAのように MC68030 20MHz 16MB的なマシンだと、
起動時のデフォルトのホームタイムライン取得の20トゥート分のjsonに対する
sjson_decode() のメモリ消費量(?)のせいでスラッシングが発生して、
タイムライン表示開始まで数時間かかることがある。
(ちなみに 24MB の sun3/60 だと分単位で出るので、そのへんに境界があるっぽい)

その対策で -tllimit オプションを作ってもらったわけですが、久しぶりに動かすと忘れがち。

対策

ホームタイムラインのJSONが ARRAYであることを想定して、ARRAY要素のトゥート単位に分解した上で
sjson_decode() に投げるようにする。

実装

適当にChatGPTにアイデアを聞くと、最初は自力でjsonをパースして要素に分解するように言われたが、
\" のエスケープチェック等々でバグるとめんどくさいから既存の実装でなんとかならないか、と聞くと
https://github.com/zserge/jsmn が軽いという話であった。

パースした結果が元のJSON文字列の先頭からの開始バイト数と終了バイト数で出てくるので、
適当にARRAY要素単位に分割して strndup() して sjson_decode() に突っ込んでやると
LUNAでも起動して 2分程度で 20トゥート分のタイムライン表示が開始されるようになった。
(TLS認証に 50秒くらいかかるので、実質1分ほど)

要検討事項

  • 起動時のタイムラインJSONのARRAY要素分解だけで新たなJSONライブラリ持ってくるのか?
    というところ。(本当に採用するならREADMEにも追記必要)
    とはいえ自前で書いてもコード量的には変わらない一方で微妙にバグりそう。
    かといって sjson を改造するのも本末転倒?
  • jsmn は動的メモリを確保しないので、トークン数を事前に見積もる必要があるが、マストドン1トゥートあたりに
    上限いくつの要素が放り込まれるのかが見積もれない。ざっと試すと 20トゥートで 3300トークンくらいになったが、
    変動量と条件がわかっていない。
  • sjson_create_context()sjson_destroy_context() をどのタイミングで呼ぶべきか、
    というのをちゃんと調べていない

@taka-tuos
Copy link
Owner

とりあえず現状考えてるところまでの報告(別件で作ってるC#ライブラリが楽しくて進まない)なんですが

検討事項について

  1. このためだけにjsmnを入れるのは別に構わないが、コンパイル時間的にどうなんですかね?
  2. 最悪値はつく属性全部ついたjsonが何トークンになるか試算すればよいので、一回試算してその数字がどんなもんかで考える(この作業が未着手)
  3. 自分もよくわかっていない、いろいろなstringはあんまりコピーされてない仕組みのはずなので(ならどうしてスラッシングするんだ?)(親をdestroyしてから触るとuse-after-freeになった)最後までしないほうがよいはず

その他?懸念事項

逆にjsmnだけにできてしまう説がなくもない(これは別件ではある)

@tsutsui
Copy link
Contributor Author
tsutsui commented Dec 17, 2024

取り込んで欲しいわけでもないけれど、なんか書いたら動いたので
とりあえずコンセプト実装として差分が見えるようにプルリクで投げた
というやつなので、このまま塩漬けでもよいですが

このためだけにjsmnを入れるのは別に構わないが、コンパイル時間的にどうなんですかね?

とりあえず Milan (68040 25MHz 128MB) で測ってみると

master 846a9ad の nanotodon.c

# time cc -O2 -fno-reorder-blocks -D_GNU_SOURCE -DSUPPORT_XDG_BASE_DIR -DUSE_SIXEL -DUSE_WEBP -I/usr/pkg/include -c nanotodon.c -o nanotodon.o
557.722u 42.221s 10:14.30 97.6% 0+0k 0+31io 0pf+0w

このブランチの b3fcc1c の nanotodon.c

# time cc -O2 -fno-reorder-blocks -D_GNU_SOURCE -DSUPPORT_XDG_BASE_DIR -DUSE_SIXEL -DUSE_WEBP -I/usr/pkg/include -c nanotodon.c -o nanotodon.o
594.145u 44.100s 10:53.22 97.7% 0+0k 0+33io 0pf+0w

時間的には stb_image.h のほうが支配的という感じはします。

逆にjsmnだけにできてしまう説がなくもない(これは別件ではある)

あんまり json の処理をちゃんと読んでないんですが、これができるなら軽くなりそうではあります。
が、 jsmn の issue を見てると 痒いところに手が届かない という雰囲気は感じますね。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants
0