As these are probably not compressible that means there really isn’t a whole lot lost compared to the optimal solution.
Just to nail the point home - couple of latest snapshots have a bug where they dont clear previous entries in Tabs_ https://www.reddit.com/r/vivaldibrowser/comments/17aqe76/tim... After ~23 restarts Tabs_ file grew to 144MB, still being rewritten every time you close a Tab :o, and grows by 6MB every restart.
How wasteful is Vivaldi/Chrome https://www.reddit.com/r/vivaldibrowser/comments/xu6o3k/bad_... :
\AppData\Local\Vivaldi\User Data\Default\Network\TransportSecurity ~700KB file is being regularly deleted and recreated
This 700KB file is being rewritten 2-4 times _per minute_ while only updating ~10 entries inside. Here is an example of whats inside TransportSecurity
https://chromium.googlesource.com/chromium/src.git/+/080fbdc...
Those entries arent even important for permanent storage ... and the only data changing is expiry. WTF is going on?
\AppData\Local\Vivaldi\User Data\Default\Preferences again ~700KB, also only useless stuff changes between rewrites, like:
"last_visited"
"language_model_counters"
"predictionmodelfetcher"
""expiration"
"last_modified"
"visits"
"lastEngagementTime"
useless stats, if anything (why would I need those exactly?) those all belong in a database file somewhere. ~100 byte change forces 700KB file rewrite multiple times per minute.\AppData\Local\Vivaldi\User Data\Default\Sessions\Tabs_ multi megabyte file (~8MB for ~300 tabs) force written with every closing of a tab. Why is it so big? After all its just a list of opened tabs, right? The answer is pretty terrifying. Its full of base64 encoded jpeg thumbnails for _every single tab preview_.
"thumbnail":"data:image/jpeg;base64
TEXT encoded images in constantly rewritten file instead of using Browser image cache!\AppData\Local\Vivaldi\User Data\Default\Sessions\Session_ same as Tabs_, ~same contents including useless base64 encoded jpegs inside, rewritten together with Tabs_.
\AppData\Local\Vivaldi\User Data\Local State 12KB, at this point its almost insignificant that we are constantly rewriting this file. This one keeps such "important" garbage as
"browser_last_live_timestamp"
"session_id_generator_last_value"
"reloads_external"
so more useless stats, 20 bytes change forces rewriting 12KB file.I sort of understand the logic behind the decision that led to making Tabs_ and Session_ files slam users SSD on every tab interaction - someone was very concerned with Vivaldi constantly losing Tabs and Sessions on browser Crash. But the way this got implemented is backwards and not exactly achieves intended goal.
1 Saves to \AppData\Local\Vivaldi\User Data\Default\Sessions happen ONLY on Tab close, not on Tab Open. You can still open 10 Tabs, have browser crash and lose those tabs.
2 Why would you store base64 encoded jpeg thumbnails when you have image cache storage in the browser?
3 Why flat file rewrites instead of leveraging SQLite, IndexedDB or LevelDB? All available natively in Chrome codebase. Two first journaled, third still claiming crash resistance.
Why am I making this post? 'I mean it's one banana, Michael. What could it cost, $10?' https://www.youtube.com/watch?v=Nl_Qyk9DSUw. Lets count together an average daily session with Vivaldi being open for 6 hours and someone opening and closing ~100 Tabs. TransportSecurity 360 minutes x 0.7 x 2 = 500MB. Preferences 360 minutes x 0.7 x 2 = 500MB. 100 Tab closes 100 x 8 x 2 = 1.6 GB. 2.6GB per day. ~ 1TB/year of system SSD endurance burned doing useless writes. A reminder "A typical TBW figure for a 250 GB SSD lies between 60 and 150 terabytes written"
Edit: Addendum for people assuming its all Chromium fault. Chrome 106.0.5249.91 released 2 days ago. Preferences and TransportSecurity are indeed being written ~1/minute :/, but Tabs_ and Session_ are NOT _on every single tab close_ like in Vivaldi. 15 minute Chrome session resulted in 3xSession_ and 2xTabs_ writes. Chrome also doesnt appear to be storing base64 encoded thumbnails in Tabs_/Session_ files. Looks like the issue is caused by Vivaldis own hack after multiple complaints about crashes resulting in lost data.
Additionally even if you dont care about SSD wear there is also issue of additional power draw for mobile users. Heavy IO is not cheap.
Edit2: Found another one:
Vivaldi creates 9 files in \AppData\Local\Vivaldi\User Data\Default\JumpListIconsVivaldiSpeedDials and immediately deletes them.
What is Jump List anyway? MS says "A jump list is a system-provided menu that appears when the user right-clicks a program in the taskbar or on the Start menu." Does Vivaldi support Jump List in the first place? Chrome does so probably yes.
How To Get Back The Jump List Of Google Chrome In Taskbar https://www.youtube.com/watch?v=WG1tv-kceF4
Sure enough after enabling "show recently opened" Vivaldi does populate it with Speed Dial items. Why is Vivaldi refreshing JumpListIconsVivaldiSpeedDials so often? It tries to Regenerate favicons for jump list items:
- Even when Jump List is disabled.
- Even if NOTHING changed on the Speed Dial.
- Even if Speed Dial "show Favicons" Setting is _Disabled_.
- Despite ALL Vivaldi Jump list Speed Dial entries using default Vivaldi icon and NEVER using favicons.
- EVERY time Session_ file is written, and those are written on _every tab close_ https://www.reddit.com/r/vivaldibrowser/comments/xu6o3k/bad_....
- and then DELETES all the generated data anyway making whole operation a huge waste of CPU and IO resources.