Skip to content
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

Garbage collect thumbnails and favicons #312

Open
jnvsor opened this issue May 1, 2019 · 1 comment
Open

Garbage collect thumbnails and favicons #312

jnvsor opened this issue May 1, 2019 · 1 comment

Comments

@jnvsor
Copy link

jnvsor commented May 1, 2019

Conex stores full resolution jpeg screenshots of every page you browse. Ignoring the potential privacy issues with this, this becomes a severe performance issue over time.

Neither closing tabs, nor disabling thumbnails and favicons will purge these images, which are stored in base64 format in the extension's storage.js file.

Note that in the case of favicons, they will continue to be stored even if you disable the option (So you might as well leave it on)

After several months of "Normal" internet use, my file contains 9991 favicons, and 15364 thumbnails. I keep a lot of tabs open, but not 15364.

This results in a storage.js of over 900 megs, which is deserialized and reserialized by the browser several times a minute, sometimes within a second of eachother.

If your storage.js has gotten to this point, every time this file is deserialized/serialized your browser will lock up for several seconds, and ram usage will climb by approx. 6GB

Even on a lightweight linux distro like bunsenlabs, with a farily high-end machine, this serves to lock up the rest of the OS as well.

The fix for a user is to delete the file and set up their conex settings from scratch (While leaving thumbnails unchecked)

Potential solutions:

  • Garbage collect thumbnails and favicons from closed tabs
  • Don't save thumbnails/favicons, just keep them in memory

Edit: While I'm referencing an old firefox build that still used json to store settings instead of sqlite, the issue is still relevant IMO. A SELECT COUNT(*) FROM object_data on the storage file took quite a while, it's taking quite a lot of space, and it's probably got sensitive information

@kesselborn
Copy link
Owner

yeah: I am aware of the problem and a complete rewrite is ongoing ... due to time constraints it won't be before July or August before this comes life.
Once rewritten, all the mentioned issues will be gone ... I currently lack the time to do a hotfix for the current version :/
Thanks for the detailed report though

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

No branches or pull requests

2 participants