Increase performance of git log on windows about githistoryvscode HOT 8 CLOSED

We could look at the the performance of http://www.nodegit.org/ source https://github.com/nodegit/nodegit
It uses libgit2 and lloks pretty active.

from githistoryvscode.

Yes I saw that too probably stick to your current way.
Native dependencies sounds like it might raise a few issues
Since reading stdout from a spawn seems slower in windows I think the best we can do is only get what we need. For example we could cut the stream (and the size of the html) down dramatically if we only get what we need to display the git log page.
If I limit the page size to 10 for example that makes a huge difference.
I think were back to an on demand loading list spawning git on demand.

from githistoryvscode.

It seems that running this command in git bash is much faster that under cmd on windows.

Anyone with knowledge of how the spawn internals work on windows?
I'm guessing spawning git would run without a shell?
I think exec is used for shell commands.

from githistoryvscode.

@mikes-gh , I did check that out when starting this project, but that's quite a huge (last time i checked) dependency.
Also its a native dependency, meaning we will need to release and update every time VS Code updates their node versions (result of updates to Atom). However its work a look once again.
I know theres a project that allows compile native modules so they work with multiple node versions (i.e. support for backwards compatibility), though not forward.

from githistoryvscode.

Another approach would be to try and see if we can somehow make use of what Visual Studio Code is using.

from githistoryvscode.

Here's the source,
It looks like VS Code too is spawning the git executable.

from githistoryvscode.

Agreed, time to shave off a few milli seconds here and there to speed this up, thought I'd default the setting to something like 20, some monitors are quite big, like the monster I have at work...
Might want to consider calculating the height and determining the number of items to be displayed (if possible).

I've always wanted to rewrite the front end component to use websockets (socket-io), this way it would be a lot more efficient (something I've successfully done in another extension).

from githistoryvscode.

Thanks for reporting this issue. Closing for now due to inactivity.

from githistoryvscode.