> I'd be curious to see the same test in C, if someone(TM) had the time.

My C is a bit rusty, but I gave Claude a whirl and it generated something that 
did the job perfectly. The difference was not quite as stark, but thread 
queries were still ~50% slower.

I've attached the code Claude generated for the curious — run as 
./notmuch-bench-something ~/.notmuch-db "date:2025"

> I agree twice as slow is not reasonable. I do expect it to be slower
> because of extra work that notmuch is doing (outside xapian) to
> construct the thread structures (parenting nodes turns out to be a bit
> non-trivial). I did also spend some effort tuning the thread:{}
> queries; the others I think have not looked at as closely.

This isn't even using thread:{}, it's just making sequential queries for each 
individual thread (the C version, the python version concatenates all thread IDs 
into a massive "thread: or thread: or thread:..." query).

At least for the C version, the performance gap narrows the more threads there 
are, which makes sense given that each new thread causes a new query in this 
very unoptimized version. But altogether, retrieving threads is substantially 
slower than messages.

Cheers,

Lars

_______________________________________________
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-leave@notmuchmail.org