[Python-Dev] PATCH submitted: Speed up + for string concatenation, now as fast as "".join(x) idiom
Kristján V. Jónsson
kristjan at ccpgames.com
Mon Oct 9 11:55:00 CEST 2006
This patch looks really nice to use here at CCP. Our code is full of string contcatenations so I will probably try to apply the patch soon and see what it gives us in a real life app. The floating point integer cache was also a big win. Soon, standard python won't be able to keep up with the patched versions out there :)
Oh, and since I have fixed the pcbuild8 thingy in the 2.5 branch, why don't you give the PGO version a whirl too? Even the non-PGO dll, with link-time code generation, should be faster than your vanilla PCBuild one. Read the Readme.txt for details.
> -----Original Message-----
> From: python-dev-bounces+kristjan=ccpgames.com at python.org
> [mailto:python-dev-bounces+kristjan=ccpgames.com at python.org]
> On Behalf Of M.-A. Lemburg
> Sent: 9. október 2006 09:30
> To: Larry Hastings
> Cc: python-dev at python.org
> Subject: Re: [Python-Dev] PATCH submitted: Speed up + for
> string concatenation, now as fast as "".join(x) idiom
> Larry Hastings wrote:
> > Fredrik Lundh wrote:
> >> skip at pobox.com wrote:
> >>> MAL's pybench would probably be better for this presuming it does
> >>> some addition with string operands.
> >> or stringbench.
> > I ran 'em, and they are strangely consistent with pystone.
> > With concat, stringbench is ever-so-slightly faster
> overall. "172.82"
> > vs "174.85" for the "ascii" column, I guess that's in seconds. I'm
> > just happy it's not slower. (I only ran stringbench once;
> it seems to
> > take *forever*).
> > I ran pybench three times for each build. The slowest
> concat overall
> > time was still 2.9% faster than the fastest release time.
> > "ConcatStrings" is a big winner, at around 150% faster;
> since the test
> > doesn't *do* anything with the concatenated values, it
> never renders
> > the concatenation objects, so it does a lot less work.
> > "CreateStringsWithConcat" is generally 18-19% faster, as expected.
> > After that, the timings are all over the place, but some tests were
> > consistently faster: "CompareInternedStrings" was 8-12% faster,
> > "DictWithFloatKeys" was 9-11% faster, "SmallLists" was
> 8-15% faster,
> > "CompareLongs" was 6-10% faster, and "PyMethodCalls" was
> 4-6% faster.
> > (These are all comparing the "average run-time" results, though the
> > "minimum run-time" results were similar.)
> When comparing results, please look at the minimum runtime.
> The average times are just given to indicate how much the
> mintime differs from the average of all runs.
> > I still couldn't tell you why my results are faster. I swear on my
> > mother's eyes I didn't touch anything major involved in
> > "DictWithFloatKeys", "SmallLists", or "CompareLongs". I
> didn't touch
> > the compiler settings, so that shouldn't be it. I acknowledge not
> > only that it could all be a mistake, and that I don't know enough
> > about it to speculate.//
> Depending on what you changed, it is possible that the layout
> of the code in memory better fits your CPU architecture.
> If however the speedups are not consistent across several
> runs of pybench, then it's likely that you have some
> background activity going on on the machine which causes a
> slowdown in the unmodified run you chose as basis for the comparison.
> Just to make sure: you are using pybench 2.0, right ?
> Marc-Andre Lemburg
> Professional Python Services directly from the Source (#1,
> Oct 09 2006)
> >>> Python/Zope Consulting and Support ...
> >>> mxODBC.Zope.Database.Adapter ...
> >>> mxODBC, mxDateTime, mxTextTools ...
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
> Python-Dev mailing list
> Python-Dev at python.org
More information about the Python-Dev