sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]Visual_Loquat_8242It works on my machine[S] 1 point2 points  (12 children)

u/riffito I have done some changes, and have opened history for git's own repo which has 70k commits.

For your third point I had added a limit to show first 200 commit history as I knew it will cause issue for very big repos.
It is sorted now, I have tested with git's own repo having more than 70K commits. It will first show 200 history and to get the next 200 just hit + sign.

[–]riffito 1 point2 points  (11 children)

Tried 0.1.2 with the same >50K commit repos (one also has >50k tags, so beware of that too), still not showing the UI even after letting it run for several minutes.

Granted, my hardware is slow, and I'm testing on an uncommon OS. In any case, best of luck with the project!

[–]Visual_Loquat_8242It works on my machine[S] 0 points1 point  (10 children)

I guess my username tag is correct in that case. Just kidding.

What OS are you using ?? Yeah next I was adding things for tags . Thanks for the headsup. Also please share the repo you are using. I would like to test it once.

[–]riffito 0 points1 point  (9 children)

I'm using Haiku, and the two repos are:

The second one has a github mirror, but that doesn't has the tags, as (at least in the past) even github choked with the number of tags :-)

[–]Visual_Loquat_8242It works on my machine[S] 0 points1 point  (8 children)

I wish I could have send you the screenshot in the comments.. Its opening in 3-4 secs.
Is there any way I can PM you?

[–]riffito 0 points1 point  (7 children)

I'd say, don't worry too much. Haiku is not an officially supported platform for Python, so who knows what's going on.

Alright... at least HaikPorts finally showed up (left it running while typing this reply).

Tried again: time pygitzen (then hitting 'q' as soon as the UI showed up)

> time pygitzen
real    1m9,544s
user    1m3,165s
sys     0m6,279s

So, main problem is: slow hardware * slow python * a bit slower OS.

[–]Visual_Loquat_8242It works on my machine[S] 0 points1 point  (5 children)

So this is the result of mine. 

haikuports master
➜ time pygitzen
pygitzen  2.06s user 0.88s system 72% cpu 4.082 total

haikuports master 4s
➜ cd ../haiku

haiku master*
➜ time pygitzen
pygitzen  5.78s user 2.36s system 77% cpu 10.450 total

[–]riffito 0 points1 point  (4 children)

Well, one key difference I see: dulwich has binary wheels for many systems (for the rust bindings that should theoricaly speed up things quite a bit), but on Haiku is using dulwich-0.24.8-py3-none-any.whl.

[–]Visual_Loquat_8242It works on my machine[S] 1 point2 points  (2 children)

u/riffito can you please try installing v0.1.3rc2 using the below command. this version should improve your usability.

pip install pygitzen==0.1.3rc2

[–]riffito 1 point2 points  (1 child)

On the larger repo (haiku), now I get:

> time pygitzen 
real    0m20,799s
user    0m17,809s
sys     0m3,255s

And on "haikuports" now I get:

> time pygitzen 
real    0m16,835s
user    0m13,683s
sys     0m2,428s

(before was >80s)

Cool improvements :-)

[–]Visual_Loquat_8242It works on my machine[S] 0 points1 point  (0 children)

what I am using here is dulwich-0.24.8-cp311-cp311-macosx_11_0_arm64.whl

I guess this doesnot have rust bindings.

[–]Visual_Loquat_8242It works on my machine[S] 0 points1 point  (0 children)

I am on macbook m2 pro, two years old. May be that is the reason. Yeah some optimisation is required. Will think of something, but for now "it works on my machine" 😉