You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Plugin tracks all discovered files in a map-like collection
(`FileWatch::WatchedFilesCollection`).
The collection design was to re-sort all elements every time the
collection gets updated ... this obviously does not scale with 10000s of
watched files.
Starting up LS with 60k files in a watched directory, locally, takes
**\~ an hour before these changes**.
**After these changes** for the plugin to start processing files it
takes **~2 seconds**.
Since the collection is known to have a noticeable (memory) footprint,
there's changes towards reducing intermediate garbage - which also
contributed to the decision to move the collection to native.
Notable changes to tracking watched files with
`FileWatch::WatchedFilesCollection`:
- predictable `log(size)` modification (and access) times
- implementation has clear locking semantics, previously operations
weren't 100% atomic
- hopefully, cleaner API as the collection re-resembles a *WatchedFile
-> String (path)* map
- the collection now needs an explicit update whenever a file changes
(on re-stat),
previous implicitness of picking up changes might have been the
reasoning behind re-sorts
(could be decoupled further by making `WatchedFile` immutable but
there's other state anyway)
---
Apart from the necessary changes to resolve the performance bottleneck,
there's also a quick review of (trace) logging - annoying to not only
see partial traces even in debug/trace levels.
Few unused methods and instance variables were removed for a better code
reading experience.
0 commit comments