view tests/test-profile @ 8849:80cc4b1a62d0

compare grep result between target and its parent I found that typical case is that grep target is added at (*) revision in the tree shown below. +--- 1(*) --- 3 0 +--- 2 ------ 4 Now, I expect 'hg grep --all' to show only rev:1 which is first appearance of target line. But 'hg grep --all' will tell: target line dis-appeared at 3 => 4 target line appeared at 2 => 3 target line dis-appeared at 1 => 2 target line appeared at 0 => 1 because current 'hg grep' implementation compares not between target revision and its parent, but between neighbor revisions in walkthrough order. I checked performance of this patch by "hg grep --follow --all walkchangerevs" on whole Mercurial repo, and patched version could complete as fast as un-patched one.
author FUJIWARA Katsunori <foozy@lares.dti.ne.jp>
date Tue, 19 May 2009 16:49:54 +0900
parents 9a1b86cfd29e
children
line wrap: on
line source

#!/bin/sh

echo % test --time
hg --time help -q help 2>&1 | grep Time > /dev/null || echo --time failed

hg init a
cd a

echo % test --profile
if "$TESTDIR/hghave" -q lsprof; then
    hg --profile st 2>../out || echo --profile failed
    grep CallCount < ../out > /dev/null || echo wrong --profile

    hg --profile --config profiling.output=../out st 2>&1 \
        || echo --profile + output to file failed
    grep CallCount < ../out > /dev/null \
        || echo wrong --profile output when saving to a file

    hg --profile --config profiling.format=text st 2>&1 \
        | grep CallCount > /dev/null || echo --profile format=text failed

    echo "[profiling]" >> $HGRCPATH
    echo "format=kcachegrind" >> $HGRCPATH

    hg --profile st 2>../out || echo --profile format=kcachegrind failed
    grep 'events: Ticks' < ../out > /dev/null || echo --profile output is wrong

    hg --profile --config profiling.output=../out st 2>&1 \
        || echo --profile format=kcachegrind + output to file failed
    grep 'events: Ticks' < ../out > /dev/null \
        || echo --profile output is wrong
fi