[Investigate] Speed issue with writing to previously deleted file
Description
While TDD'ing [Feat] Create VSCode SourceControl based on rea... (#11 - closed) I discovered a test case that had some pretty lousy performance:
Investigation
Diving into the flame chart, I discovered that we end up in a highly repetitive stat
cycle:
After some step through debugging, I found that an error Uncaught Error: unlock of a non-locked mutex
was being thrown a lot... This sounded like some operations were not being closed properly...
After some more debugging with the problem right under my nose, I discovered this LOC in browserFS where the callback of the function can actually be triggered twice!
I'd expect browserfs
to return after calling the cb
... In fact, when manually adding a return
through the chrome debugger, the tests still pass and are just as speedy as the other ones
Options
Unfortunately browserfs has not had much activity in the past years... I doubt we can submit a fix upstream...
Here's some options to consider:
- Copy over the https://github.com/jvilk/BrowserFS/blob/v1.4.3/src/backend/OverlayFS.ts#L357 module into our own codebase and make the fix there.
- Look into another file system library. Thankfully BrowserFS is just an implementation detail to us. This
@file-services/...
package seems interesting, but upon looking at theiroverlay
implementation, I'm not sure if it's as mature as BrowserFS🤔 ... Maybe there's another stable and mature BrowserFS-esque file system library out there?