Lag and high CPU usage on large repositories holding enter-key about geometry HOT 16 CLOSED

A bit caught up in work this week. I'll try to do it in the next couple of days.

Actually I was recently wondering if you were going to continue that PR. I'll definitely check perf! I've been wanting to have a good excuse to go into that for ages! ❤️

from geometry.

I always knew that much forking would come back and bite us.

Well, caching the rprompt may seem like a good solution but I'm not sure if I like it. How high is the probability that something has changed between the two consecutive prompt writes?

Also is this a symptom of a different problem: is our solution not enough? Should we consider switching to zsh-async?

from geometry.

I could try to switch between our home made implementation and zsh-async as a experiment and see if there is a difference in this regard.

I believe that caching could work in this particular context (by caching by very small amount of time, ie, <1s).

from geometry.

Well, our solution is simple and maintainable. I'd rather have that instead of having other dependencies.

I'm curious about the performance of both solutions though. How about we test them?

from geometry.

Yeah, I wanted to try zsh-async for awhile but never found a good excuse to use it.

Anyways the issue is with exec + killing subprocesses. I don't remember the reason why I choose to opt for kill a running subprocess rather than let it finish and avoid firing up a second one.

from geometry.

I remember, it was because it may show stale/invalid information.

Say I let a 5 second process run, meanwhile the user issues a git checkout other-branch, then I print the result from the long-running process. I'll end up displaying the branch info from the previous checkout.

But anyways, taking a further look it seems that long-running git process do "lock" the git repository so it's unfeasible there is anything changing meanwhile. At least nothing obvious.

So, for the time being I'll take a look into:

• What is the git command that causes the .git/index.lock. See if it can be avoided.
• Try out zsh-async. Avoid killing long-running processes.

from geometry.

Maybe related: https://gist.github.com/sindresorhus/3898739

from geometry.

I tried implementing cache at async lib and git plugin levels and both seems to be quite problematic. So I'm discarding that idea completely.

I made some perf improvements at #68 thou.

from geometry.

Do we want to close this just yet?

from geometry.

It was closed automatically from #68.

from geometry.

Looking back, the alternative would be to switch to zsh-async, right?

I wanted to avoid adding dependencies to the project but we are definitely lacking performance. You said earlier you wanted to try out zsh async. Do you want to take this or should I?

from geometry.

I'm gonna take a look today, quite busy lately.

from geometry.

@frmendes Could you take a look at #88 and review zsh-async perf. From my side it's slower than our bare-bones implementation.

Maybe it's something wrong with my implementation but I can't catch it.

from geometry.

Can we have an update on this? Using the latest geometry version I have no lag issues on smaller repos (which were a problem as well) and my shell start time is at around ~0.15s

from geometry.

I tried this on the openframeworks/openFrameworks respository, which has about 16,000 commits over 6+ years, with master checkout taking up 3.7G. Holding down enter did not slow anything down any more than any other non-git repository.

from geometry.

I'd say this is a win for our async implementation ❤️

from geometry.