Status of speed regressions...

Jason Harris jason at jasonfharris.com
Fri Nov 19 14:09:12 CST 2010


Hi,

Well...

As an aside I have also pondered doing this in the past. However, MacHg is multithreaded and launches several mercurial sessions in parallel. I guess I could try and manage a pool of these shells, but then I have to be careful if one of these links becomes corrupted, or one of the particular python-mercurial commands leaves something in a bad state... From what I understand the normal test suite does not test for this. Eg lets say some extension or something sets some internal state in the python-mercurial session during the execution of say "hg strip somerev". Normally almost all the testing and most people who use Mercurial would have their session exit after that command. But instead this shell would continue executing the next command I give it say "hg log someargs". Who is to say that this command will not trip across some state set up by the strip command (maybe some path got set or something... I have no idea, but I gather this thing isn't regularly tested for? Maybe I am wrong here...)

Maybe this really isn't a problem in practice and the crew members would be astounded to find any extension or Mercurial command that did this... Comments? :)

Anyway thanks for the suggestion! However, fixing the speed regressions is important in any case... Thus are their any patches I can use to fix these regressions?

Thanks!
   Jas


On Nov 19, 2010, at 8:07 PM, Greg Ward wrote:

> On Fri, Nov 19, 2010 at 12:40 PM, Jason Harris <jason at jasonfharris.com> wrote:
>> I was just wondering what the status of fixing the speed regressions is? Are there patches I can apply?
>> 
>> As many of you will know the proscribed way for clients like, MacHg, Murky, SourceTree, etc is to work through the normal command interface, ie not link directly to the internals of Mercurial. As such if there is a 20% or more slow down in Mercurial, our tools become 20% slower (or more). Often due to refreshing and other issues these clients issue many mercurial commands a second. At least MacHg sometimes does in order to be in sync with changes, queries, etc.
> 
> The fix for this is simple and obvious: write an extension that
> exposes a "Mercurial shell", where you can just run "status" or
> "update" or "log" without the overhead of a new Python process.  Then
> have MacHg or MercurialEclipse control this process through a pipe or
> a socket.
> 
> In fact, ISTR that someone even posted the code here a few months ago.
> It was tiny: like 20 lines or something.  If you can package that
> extension with your GUI, you're done.
> 
> Greg



More information about the Mercurial-devel mailing list