From: | "David E(dot) Wheeler" <david(at)kineticode(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: PATCH: CITEXT 2.0 v3 |
Date: | 2008-07-14 20:11:59 |
Message-ID: | 3DBB7578-3FE4-4FB6-A594-313BA7C7BD8D@kineticode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Jul 12, 2008, at 15:13, David E. Wheeler wrote:
>> 2. It's ridiculously slow; at least a factor of ten slower than doing
>> equivalent tests directly in SQL. This is a very bad thing. Speed
>> of
>> regression tests matters a lot to those of us who run them a dozen
>> times
>> per day --- and I do not wish to discourage any developers who don't
>> work that way from learning better habits ;-)
>
> Hrm. I'm wonder why it's so slow? The test functions don't really do
> a lot. Anyway, I agree that they should perform well.
Just as an FYI, I've just moved all the tests to regular SQL instead
of using pgTAP. The difference in runtime is:
psql -Xd try -f sql/citext.sql 0.03s user 0.02s system 19% cpu 0.253
total
psql -Xd try -f sql/citext.sql 0.03s user 0.02s system 4% cpu 1.298
total
So it's close to a factor of five, though subtract .125 for the time
to load the pgTAP functions. The pgTAP tests *are* doing a lot more
work, but I'm sure that they could be made a lot more efficient,
though of course the TAP functions will always introduce some
overhead. One just needs to decide whether the tradeoffs are worth it.
Best,
David
From | Date | Subject | |
---|---|---|---|
Next Message | David Fetter | 2008-07-14 21:19:52 | Re: Postgres-R source code release |
Previous Message | Bruce Momjian | 2008-07-14 19:49:16 | Re: Security and Data Protection Issues |