<div dir="ltr">On Tue, Aug 21, 2012 at 1:59 PM, Martin Geisler <<a href="mailto:mg@aragost.com">mg@aragost.com</a>> wrote:<br>><br>> Hi guys,<br>><br>> I've been working on making Mercurial faster on Windows: a client<br>
> contacted us because TortoiseHg was super slow: clicking on the "working<br>> directory" line took 15 seconds. This is with Windows XP on a fast<br>> machine. The repository has about 75k files, is on a SSD, and virus<br>
> scanning was disabled for the working copy.<div><br></div><div>Cool stuff!</div><div><br></div><div>You can probably get a significant boost from porting chg[1] to</div><div>Windows too.</div><div><br></div><div>><br>
> Some spring cleaning brought down the number of files, but to make<br>> things faster I've begun implementing a statdaemon -- an inotify-like<br>> daemon that will keep track of the file system state.<br>><br>
> It's on Bitbucket:<br>><br>>   <a href="https://bitbucket.org/aragost/statdaemon">https://bitbucket.org/aragost/statdaemon</a><br>><br>> On a repository with 63k files, 'hg status --time' goes from 2.9 sec to<br>
> 1.8 sec with the extension enabled. I get the same result with<br>> Measure-Command in PowerShell.<br>><br>> Strangely, I see the time go from 2.4 sec to 2.7 sec when I use 'hg<br>> perfstatus' to measure the time.<br>
><br>><br>> Bugs:<br>><br>> With the big tree, I see stale results in 'hg status', even though I see<br>> that the statdaemon is updating its cache when I make changes. I haven't<br>> tracked this down yet and the tests (yay, tests on Windows!) haven't<br>
> captured it yet.</div><div><br></div><div>Pretty sure the file notification API is known to sometimes fail to</div><div>report some changes. Especially when there's a burst of incoming</div><div>changes that cause some underlying buffer to fill up.</div>
<div><br></div><div>[1] <a href="https://bitbucket.org/yuja/chg">https://bitbucket.org/yuja/chg</a></div></div>