t_wの輪郭

https://addons.mozilla.org/ja/firefox/addon/web-prowler/

• 推薦ページのタイトルを短く切り詰めて表示
• メモリーリークを修正
  • XMLHttpRequestからFetchに変更。
• 高速化
  • PageのtokensをArrayからSetに変更
  • 推薦ページの計算中は、ページが登録されないように変更

メモリが90%台のところに来ると落ちている。indexedDBか、localforageがメモリーリークしてる？
保存している量というよりは、読み書きの回数な気がする。要検証。一度ローカルへの保存を止めてみよう

→XMLHttpRequestがメモリリークしていた。XMLHttpRequestの処理をpanel.jsへ移動させて、推奨ページを表示する際に更新がかかるようにすれば、強制的にメモリーを解放させられるはず
　→ダメだった。メモリー消費は変わらず、サイドバーが重たくなっただけだった

→Fetchに置き換えたら治ったっぽい。メモリーの増減が安定している。
　→ダメだった。メモリーの消費は抑えられたが相変わらず落ちる

→気が付かない間にメモリーが消費されていた。動画などの大きいデータを取ってきてしまうと、メモリーに直撃してしまうので、クローラがHTMLだけを取りに行くようにする。
　Acceptにtext/html,application/xhtml xml,application/xml;を設定した。よくわかってないがこれでHTML,XHTML,XMLだけが取られてくるようになるはずだ。
Assertも追加した。取ってきたファイルサイズがAMAZONの欲しいものリストの100倍以上の時にエラーを出してくれる。これでどういったデータで問題が出ているかがわかるようになる。最悪停止するから調査ができる。アンドンだ。

→トイレでうんこしてる間にFirefoxが落ちた。文字通りの>クソ<アドオンである。ログをファイル出力しないと、調査もままならない。Firefoxにログのファイル出力機能が見つからない以上、Web Prowler自身にそういうスクリプトを組むしかない。
　→やめた。ファイル出力したとしても、エラーをハンドルしなければいけないので無理だった。

→pages_register_on_messageに排他制御を入れたらメモリー消費が劇的に減った。同時に実行するとだめらしい。

長時間動作させて、どうなるかをこれから確認。

作業に当たって、小規模ながら工程表を作った。作業がスムーズだったと思う。

https://stackoverflow.com/questions/39285158/huge-memory-leaks-with-xmlhttp-post-request

XMLHttpRequestの使い方が悪いとメモリーを消費する

XMLHttpRequestが悪さしてそうな気がする。
どうやってテストしたものかな。
localhostにアクセスするのが安全だろうか。

先にfirefox開発ツールのperformanceを一度見た方が良さそう
ガベコレが頻発していたら、そのオブジェクトの生成を抑制すればいい