localStorage access is slow

[jrieken]

• scripts\code.sh
• hide viewlet
• close all editors
• restart profiler, reload, stop profiler
• 🐌 you see 135ms spend in index.html reading the theme from local storage (I assume the times vary with the size/history of the workspace)

CPU-20170112T105633.cpuprofile.zip

[bpasero]

For more reasons than just performance, local storage should be file based.

[jrieken]

How is this upstream? Surly local storage is file based (how else should it work) the problem is that we need to load all of local storage to read a single value. That the local storage API and I don't see that changing. I think we should just stop using locale storage and implement our own storage mechanism.

[jrieken]

StorageService#setWorkspaceId "nicely" exposes this and blocks startup

[jrieken]

Simple experiment I ran is to start with code-insiders --prof-startup, one time with the LocalStorage folder as it is today (for me ~9MB) and once with a fresh, empty folder. Difference is around ~150ms.

I'd say this one of the last low hanging items that can save a significant chunk of startup performance

with data

without data

[jrieken]

@bpasero Unrelated question: what does cleanupWorkspace do and why does it run every time I open a workspace and why does everything need to wait for this?

[bpasero]

@jrieken I think it is just the first guy who uses local storage that pays the price of it. If I remove that call, the next one hits it right after:

The cleanup is useful in cases where a folder was deleted and then recreated with the same name. We store the ctime of a folder in local storage and compare it to the ctime of the folder that is opened. If the path is the same but the ctime different, we clear all storage for that workspace early on assuming that the folder was deleted and recreated.

[bpasero]

Via #64719, we are not using window.localStorage anymore.