Databases
StackOverflow2013
Postsdbo
POTortoiseHg is Slow
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POTortoiseHg is Slow
    primarykey
    data
    text
    <p>Basically, what it says on the tin: TortoiseHg is slow.</p> <p>My team moved from Subversion to Mercurial recently. (In part to take advantage of Kiln for Code Reviews) One of the things we've noticed is that interacting with Mercurial through TortoiseHg is painfully slow. Some stats:</p> <ul> <li>Open TortoiseHg Workbench: 8 minutes 13 seconds</li> <li>Response time when clicking on a revision: 2.8 seconds</li> <li>Time to "Refresh Current Repository": 6.4 seconds</li> <li>Time to check for incoming changes: 12.8 seconds</li> </ul> <p>All this really adds up to a very slow feeling application. For reference, here are the command line tool times:</p> <ul> <li><code>hg status</code>: 4.573 seconds</li> <li><code>hg incoming</code>: 12.150 seconds</li> </ul> <p>The command-line times seem to jive with the workbench times, but the workbench makes the delay much more frustrating, because it is synchronous with the use of the program. For example, a typical task is "get the latest stuff my coworker just pushed". It looks like this (only listing the time spent waiting on the computer, rounded):</p> <ul> <li>Open TortoiseHg: 10 minutes.</li> <li>Open the appropriate repository by double-clicking in the repository registry: 5 seconds.</li> <li>Commit local changes that need committing: <ul> <li>Click on "Working Directory": 5 seconds.</li> <li>Select important files and type a commit message.</li> <li>Press Commit: 20 seconds.</li> </ul></li> <li>Get coworker's changes: <ul> <li>Check for incoming changesets: 10 seconds.</li> <li>Review them.</li> <li>Accept incoming changesets: 40 seconds.</li> </ul></li> <li>Shelve unready changes: <ul> <li>Open Shelve dialog: 2 seconds.</li> <li>Shelve remaining files: 6 minutes</li> <li>Refresh: 5 seconds.</li> </ul></li> <li>Merge: <ul> <li>Click the other head: 3 seconds.</li> <li>Merge with local:</li> <li>Wait for "Clean" verification: 15 seconds.</li> <li>Wait for merge (assuming no conflicts): 10 seconds.</li> <li>Commit: 30 seconds.</li> </ul></li> <li>Unshelve changes: <ul> <li>Open Shelve dialog: 2 seconds.</li> <li>Unshelve: 6 minutes.</li> <li>Refresh: 5 seconds.</li> </ul></li> </ul> <p>Total: 24 minutes, 32 seconds.</p> <p>Twelve of those minutes are spent shelving and unshelving. Ten are spent just opening. One consequence of this is that people tend to commit stuff they aren't sure will go anywhere just in order to avoid the shelving cost. But even if you assume no shelving and no opening cost (maybe you just leave it open), it still takes 2 and half minutes of meticulous clicking to get the latest stuff.</p> <p>And that doesn't even count the more significant stuff like cloning and whatnot. Everything is this slow.</p> <p>I have:</p> <ul> <li>Disabled antivirus.</li> <li>Disabled indexing.</li> <li>Rebooted.</li> <li>Tried it on 3 different versions of windows.</li> <li>Tried in on varying hardware, most of it reasonable quality: Core 2 Duo @3.16 GHz, 8Gb Ram.</li> <li>Tried it on 32 and 64 bit OSs.</li> <li>Tried it disconnected from a network.</li> </ul> <p>The repository is actually two repositories: a primary repo and a sub-repo that contains all our third-party binaries. The <code>.hg</code> folder of the primary repo is 676 MB. The <code>.hg</code> folder of the sub-repo is 641 MB. The contents of <code>default</code> in the primary repo is 7.05 GB. The contents of <code>default</code> in the sub-repo is 642 MB. The average file size in the main repo is 563 KB. The max file size in the main repo is 170 MB. There are 13,438 files in the main repo. The average file size in the sub-repo is 23KB. The max file size in the sub-repo is 132 MB. There are 57087 files in the sub-repo.</p> <p>I have big-push, caseguard, fetch, gestalt, kbfiles, kiln, kilnauth, kilnpath, mq, purge, and transplant extensions enabled.</p> <p>Any ideas where to start figuring out how to speed stuff up? The slowness is driving us crazy.</p>
    singulars
    1. PO
      singulars
      1. PTAnswer
    1. This table or related slice is empty.
    1. PTQuestion
    1. USalficles
    1. USalficles
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    2. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. POTortoiseHg is Slow
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. POTortoiseHg is Slow
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. POTortoiseHg is Slow
      1. This table or related slice is empty.
      1. VTUpMod
    1. COHow big is the repository ?
      singulars
      1. POTortoiseHg is Slow
      1. USdriis
    2. COI wonder if it is trying to access / timing out on network drives? Maybe try running it on a machine not on the network, even if it is just to test startup time of the Workbench.
      singulars
      1. POTortoiseHg is Slow
      1. USprunge
    3. COIt’s definitely not normal TortoiseHg speed, here it is lightning fast.
      singulars
      1. POTortoiseHg is Slow
      1. USLaurens Holst
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload