`git bug ls` should be faster

Labels: Easy pick

Timeline

Kirill Maltsev (maltsev) opened

Thanks for the great tool 👍

I tested it a bit and noticed that listing even a few dozens of bugs takes 1+ second.

Could it be optimized or is it an implementation restraint?

Michael Muré (MichaelMure) commented

Interesting. Could you tell me exactly what you are doing ? What is "listing" ?

There is a cache on disk that is built the first time you run a command and is kept updated when bugs change. That should give you a fast way to query/filter/sort bugs.

I made some performance testing a while back (https://github.com/MichaelMure/git-bug/issues/5#issuecomment-420689243) and I could fully read 10k bugs in 40 seconds.

Kirill Maltsev (maltsev) commented

Sure, here is the code I used for testing:

mkdir git-bug-test/
cd git-bug-test/
git init
seq 1 1000 | xargs -n 1 -I % git bug add -t title% -m message%

time git bug ls | wc -l
# 1000
# real	0m25.722s 

# Run ls command again assuming there has been cache built after the first run
time git bug ls | wc -l
# real	0m29.336s

Same empty repository with 100 bugs produces the following results:

time git bug ls | wc -l
# 100
# real	0m4.175s

time git bug ls | wc -l
# real	0m2.839s

I have MacBook Air (Mid 2012, macOS Mojave) with a regular SSD with git 2.17.2 (Apple Git-113) and git-bug 0.4.0 installed.

Let me know if you need more information or some extra testing. I'll be happy to do it.

Michael Muré (MichaelMure) commented (edited)

Ha, I see now. So what happen is that git bug ls will really load and compile each bugs because:

  1. this code was written long before the cache existed (it's still pretty much the same as when introduced in day 4 of the project https://github.com/MichaelMure/git-bug/commit/519c5acdd88fc349e3972862887a6e919eb5e7c2)
  2. not all needed informations are in the cache (the title especially is not, although it would make sense to have it)

So yeah, it could and should be made much faster.

Steps to do that:

  1. Add the title in BugExcerpt (while you are at it, make a new type of filter for the query language ?)
  2. Add a new ResolveBugExcerpt(id string) (*BugExcerpt, error) function in RepoCache
  3. Make the ls command works with only the BugExcerpt, not the full Bug

Michael Muré (MichaelMure) added label Easy pick

Michael Muré (MichaelMure) changed the title from `git bug ls` should be faster to `git bug ls` should be faster

Michael Muré (MichaelMure) commented (edited)

FYI, it's being worked on in https://github.com/MichaelMure/git-bug/pull/100 by @sladyn98.

It's slighly faster:

Before: real 0m3,233s After: real 0m0,011s

Just about 300x faster.

Michael Muré (MichaelMure) closed the bug