Fix find_files slowness with SQLite FindIndex (#354). - #366
Conversation
Signed-off-by: namabeeru <github.body594@passmail.com>
…heck fix: detect source checkout updates
|
@makiroll1125 I've pushed an improvement for this issue. There isn't really a single best solution since each approach has tradeoffs, but this should make search work better than the previous one. Would appreciate a review. |
makiroll1125
left a comment
There was a problem hiding this comment.
I listed some suggestions regarding search patterns and issues I noticed.
Replace per-call os.walk with a cached filename index and watchdog updates while keeping existing path semantics and output shape.
1821fb1 to
da0be4a
Compare
I’ve implemented the required changes, please review when you’re free. |
New commit here: f71d591 I also noticed some other issues regarding incorrectly set parameters that was causing CraftBot to rebuild the entire index each time |
Sure! |
|
@makiroll1125 I've pulled it to my local branch. Feel free to merge it. |
Fixes #354
So basically I added a new file,
app/utils/file_index.py, that builds a SQLite index of filenames (FTS5 trigram on the basename). It lives at{base_directory}/.craftbot/findindex.db.From the outside,
find_filesbehaves the same:base_directorystill goes to home$Recycle.Binstatus,matches, andmessage- all matches, nohead_limitThe difference is recursive searches hit the index instead of running
os.walkevery single time. Non recursive is unchanged - still just a top level glob.After the first build,
watchdogkeeps the index updated with a 5 second debounce.Also added
**/.craftbot/to.gitignoreso those runtime DB files don't get committed.