> > While I generally try to limit my use of "hg log" to focused queries > > (e.g., -k <bugid>), there are times when I need to dig through the history > > with "hg log | less" to find a specific integration of interest. However, > > with hg 1.1.2 on a local clone of onnv-gate this ends up being unusable. > > > > In particular, the first few pages of output show up in a sluggish-but- > > tolerable 10-15 seconds. However, as I page further through the history, > > the stalls more than double at each instance: first 45 seconds, then > > 1m22s, then 3m04s, etc. During these stalls, prstat shows "hg" on-cpu the > > whole time but truss shows little going on (just some periodic examination > > of .hg/store/00changelog.d), so I presume it's cpu-bound in an inefficient > > algorithm, but I'm unsure how to debug this further (in Python). > > > > Has anyone else experienced this? > > Is this on the entire gate (not specifying a file)?
Right. > I'm not seeing this on my machine, but it's a pretty nice one. Even > over NFS (/ws/onnv-clone), I can page through the history about as fast > as I can hit the space bar. > > Mercurial has some profiling built in. It can use the native Python > profiler if you specify --profile before the subcommand, and there's an > --lsprof flag as well, but that will likely point you at extra software to > download. I tried using --profile; it's been stuck at: exception raised - generating profile anyway ... for the last 20 minutes; prstat again shows hg spinning on-cpu. Seems like there may be a more systemic problem here, though the problem doesn't appear to be isolated to a specific machine or repo. -- meem _______________________________________________ tools-discuss mailing list tools-discuss@opensolaris.org
