public inbox for git@vger.kernel.org 
 help / color / mirror / Atom feed

From: David Kastrup <dak@gnu•org>
To: git@vger•kernel.org
Subject: Turning a test script into something usable in t/perf
Date: Wed, 12 Feb 2014 17:26:42 +0100	[thread overview]
Message-ID: <877g909u0t.fsf@fencepost.gnu.org> (raw)

[-- Attachment #1: Type: text/plain, Size: 126 bytes --]


Hi,

I find that I have little clue about how to convert the following brief
test script into some test to place in t/perf:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: blame-catastrophe.sh --]
[-- Type: text/x-sh, Size: 302 bytes --]

#!/bin/sh
rm -rf /tmp/git-test
mkdir /tmp/git-test
cd /tmp/git-test
git init
LIMIT=200000
yes a|head -$LIMIT >data
yes b|head -$LIMIT >data2
git add data data2
git commit -m "split"
git rm data2
yes 'a
b' | head -$(($LIMIT*2)) >data
git add data
git commit -m "combined"
time git blame data >/dev/null

[-- Attachment #3: Type: text/plain, Size: 943 bytes --]


The variable LIMIT is the deciding factor for determining performance
which, with the code in current master, is rather measurably O(LIMIT^2).
I think that the current test takes about 15 minutes to complete on my
computer.

Obviously, that's sort of excessive: there is little point in choosing
sizes that show off more than two orders of magnitude in improvement.

Now the pathological cases are lots of small but attributable fragments
in the blamed source files.  One real-world project that is hit rather
hard is an alphabetically sorted large list of words that tends to get
insertions/deletions of few scattered lines at a time.

Should one aim for an actually pathological case like in this script?
Should one try benchmarking with one of the stock repositories instead
that don't really demonstrate well just how bad the behavior might
become and which code passages are dominant regarding the quadratic
behavior?

-- 
David Kastrup

                 reply	other threads:[~2014-02-12 16:26 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=877g909u0t.fsf@fencepost.gnu.org \
    --to=dak@gnu$(echo .)org \
    --cc=git@vger$(echo .)kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox