3 ms·

> I did some research to find why this took so long. 13 years ago, extensions.json used to be extensions.sqlite. Nowadays, extensions.json is serialized and rew

by layer8 7mo ago

> I did some research to find why this took so long. 13 years ago, extensions.json used to be extensions.sqlite. Nowadays, extensions.json is serialized and rewritten in full on every write debounced to 20 ms, which works fine for 15 extensions but not 84,194. Occasionally, databases are useful. ;)

Waterluvian 7mo ago
This is probably a good example of the opposite. It would be a mistake to design for the fleetingly rare case. If you’re dealing with a handful of extensions, a json file that’s rewritten is fine.
- deleted 7mo ago
  [deleted]
- HPsquared 7mo ago
  In an ideal world, software with 100 million users would be optimised for energy usage. It all adds up. This does pale in comparison to everything else, though.
- shakna 7mo ago
  But the software already has multiple database systems built in. There's not exactly overhead to use what plumbing is already there, instead of writing to disk.
  - estimator7292 7mo ago
    Easier for a user to edit.
    - deleted 7mo ago
      [deleted]
  - Chaosvex 7mo ago
    Firefox is absolutely abysmal at not corrupting its JSON stores, too. I've had it crash and lose tabs so many times. Perhaps moving back to SQLite wouldn't be a bad idea. I had to recover somebody's bookmarks for them recently after it decided to destroy the main copy.
    - mockingloris 7mo ago
      > I had to recover somebody's bookmarks for them recently after it decided to destroy the main copy. @Chaosvex curious how you did that.
      - Chaosvex 7mo ago
        Thankfully, it makes backups inside the profile folder and has a bookmarks file import option that'll accept them. It does the same for session tabs (minus the import options) but that never seems to actually work.
    - andOlga 7mo ago
      The SQLite parts that exist in Firefox right now are no less fiddly. If you crash the thing and the journal files are still there, it starts back up and presents you with a blank profile. Absolutely horrifying if you don't know about this quirk (and about the fact that you can go in and delete those even after such a restart happens).

by layer8 7mo ago

Waterluvian 7mo ago

This is probably a good example of the opposite. It would be a mistake to design for the fleetingly rare case. If you’re dealing with a handful of extensions, a json file that’s rewritten is fine.

deleted 7mo ago
[deleted]
HPsquared 7mo ago
In an ideal world, software with 100 million users would be optimised for energy usage. It all adds up. This does pale in comparison to everything else, though.
shakna 7mo ago
But the software already has multiple database systems built in. There's not exactly overhead to use what plumbing is already there, instead of writing to disk.
- estimator7292 7mo ago
  Easier for a user to edit.
  - deleted 7mo ago
    [deleted]
- Chaosvex 7mo ago
  Firefox is absolutely abysmal at not corrupting its JSON stores, too. I've had it crash and lose tabs so many times. Perhaps moving back to SQLite wouldn't be a bad idea. I had to recover somebody's bookmarks for them recently after it decided to destroy the main copy.
  - mockingloris 7mo ago
    > I had to recover somebody's bookmarks for them recently after it decided to destroy the main copy. @Chaosvex curious how you did that.
    - Chaosvex 7mo ago
      Thankfully, it makes backups inside the profile folder and has a bookmarks file import option that'll accept them. It does the same for session tabs (minus the import options) but that never seems to actually work.
  - andOlga 7mo ago
    The SQLite parts that exist in Firefox right now are no less fiddly. If you crash the thing and the journal files are still there, it starts back up and presents you with a blank profile. Absolutely horrifying if you don't know about this quirk (and about the fact that you can go in and delete those even after such a restart happens).