Nicko wrote:
> I note that in both of those tests you didn't actually ever realise the
> concatenated string. Can you give us figures for these tests having
> forced the concatenated string to be computed?
Sure, good call. And bad news.
All these benchmarks were with functions taking N argument
Larry Hastings wrote:
> It's *slightly* slower for two:
>
> def addTwoThings(a, b):
> return a + b
> for i in range(1000):
> x = addTwoThings("aaa", "bbb")
...
> But starts paying off already, even with three:
>
> def addThreeThings(a, b, c):
> return a + b + c
> for i in range(1000
"> Forgot to mention this, in case you haven't done so post your original
> message/patch on the python-dev lists since that's where the decisions
> are made. This group is more end-user oriented.
>
> http://mail.python.org/pipermail/python-dev/2006-October/thread.html
It is often good to get com
Larry Hastings wrote:
> That patch addressed the same general problem, but took a completely
> different approach. For the record, this patch (#980695) optimized "x
Larry,
Forgot to mention this, in case you haven't done so post your original
message/patch on the python-dev lists since that's w
Istvan Albert wrote:
> I remember a similar patch from some time ago:
> > http://mail.python.org/pipermail/python-dev/2004-August/046686.html
That patch addressed the same general problem, but took a completely
different approach. For the record, this patch (#980695) optimized "x
+= a" by examini
I remember a similar patch from some time ago:
http://mail.python.org/pipermail/python-dev/2004-August/046686.html
i
--
http://mail.python.org/mailman/listinfo/python-list
John Machin wrote:
> Don't you mean y = x[1] or something like that? y = "".join(x) looks
> like a copy-paste error.
You're right, by gum. Worse than that, my benchmark wasn't actually
*doing* much of anything there; at the end of the run x was still
length 0. That was sloppy, and I apologize.
Larry Hastings wrote:
>
> John Machin wrote:
> > try benchmarking this ... well "style" may not be the appropriate word
>
> Running this under Python 2.5 release:
> x = []
> xappend = x.append
> for i in xrange(1000):
> xappend("a")
> y = "".join(x)
> took 3281ms.
>
>
Fredrik Lundh wrote:
> You should also benchmark this against code that uses the ordinary
> append/join pattern.
Sorry, thought I had. Of course, now that the patch is up on
Sourceforce you could download it and run all the benchmarks you like.
For all the benchmarks I ran below, the number list
In article <[EMAIL PROTECTED]>,
Larry Hastings <[EMAIL PROTECTED]> wrote:
>Steve Holden wrote:
>>
>> I think your project might make a very
>> interesting PyCon paper for people who were thinking about joining the
>> development effort but hadn't yet started.
>
>Perhaps; I've never been to PyCon, b
Fredrik Lundh wrote:
>
> You should also benchmark this against code that uses the ordinary
> append/join pattern. (you've posted conflicting benchmarks for 2.5,
> but if I'm trusting the benchmarks that looks more reasonable, the
> standard implementation pattern is still around 10 times faster
Larry Hastings wrote:
> There are some improvements in this version. Specifically:
>
> * Python will no longer crash if you do ten million prepends
> ( x = 'a' + x ). Since the problem was blowing the stack
> with an incredibly deep render, I now limit the depth of
> the string concatenat
An update: I have submitted this as a patch on SourceForge.
It's request ID #1569040.
http://sourceforge.net/tracker/?group_id=5470&atid=305470
I invite everyone to take it for a spin!
There are some improvements in this version. Specifically:
* Python will no longer crash if you do ten
Congratulations on the clear way in which you have set out your proposal.
I hope that it will make its way to PEPdom.
Colin W.
Larry Hastings wrote:
> This is such a long posting that I've broken it out into sections.
> Note that while developing this patch I discovered a Subtle Bug
> in CPython
Larry Hastings wrote:
> Fredrik Lundh wrote:
>
>>so what does the benchmark look like if you actually do this ?
>
>
> Okay, timing this:
> x = ""
> for i in range(10):
> x += "a"
> t = x[1] # forces the concat object to render
>
> The result:
> Python 2.5 release: 30.0s
> Pyth
Larry Hastings wrote:
[snip]
> The core concept: adding two strings together no longer returns a pure
> "string" object. Instead, it returns a "string concatenation" object
> which holds references to the two strings but does not actually
> concatenate
> them... yet. The strings are concatenated
Fredrik Lundh wrote:
> so what does the benchmark look like if you actually do this ?
Okay, timing this:
x = ""
for i in range(10):
x += "a"
t = x[1] # forces the concat object to render
The result:
Python 2.5 release: 30.0s
Python 2.5 locally built: 30.2s
Python 2.5 concat: 4
Larry Hastings wrote:
>
> At the exact moment that the loop is done, it's a
> PyStringConcatenationObject * which points to a deep one-sided tree of
> more PyStringConcatenationObject * objects. Its ob_sval is NULL, which
> means that the first time someone asks for its value (via the macro
> PyS
Fredrik Lundh wrote:
> >> what's in "s" when that loop is done?
> > It's equivalent to " 'a' * 1000 ". (I shan't post it here.)
> but what *is* it ? an ordinary PyString object with a flattened buffer,
> or something else ?
At the exact moment that the loop is done, it's a
PyStringConcatenat
William Heymann wrote:
> This is a pretty small change but I would suggest xrange instead of range.
Good point! Since I was calling range() during the benchmark, it was
timed too. Switching to xrange() will mean less overhead.
I re-ran this benchmark (again):
s = ""
for i in range(10):
Larry Hastings wrote:
>> what's in "s" when that loop is done?
>
> It's equivalent to " 'a' * 1000 ". (I shan't post it here.)
but what *is* it ? an ordinary PyString object with a flattened buffer,
or something else ?
--
http://mail.python.org/mailman/listinfo/python-list
On Friday 29 September 2006 08:34, Larry Hastings wrote:
> It would still blow up if you ran
> s = ""
> for i in range(1000):
> s = "a" + s
This is a pretty small change but I would suggest xrange instead of range.
That way you don't allocate that large list just to throw all the ite
Fredrik Lundh wrote:
> > Sure. Here are the results, but with range (1000):
> ten million? what hardware are you running this on?
Athlon 64 x2 4400+ (aka 2.2GHz), 3GB of RAM, Windows XP.
> what's in "s" when that loop is done?
It's equivalent to " 'a' * 1000 ". (I shan't post it here
Larry Hastings wrote:
>> Nice idea, though. You might also see how it does on tasks like
>>
>> s = ""
>> for i in range(10):
>> s += "a"
>
> Sure. Here are the results, but with range (1000):
ten million? what hardware are you running this on?
> Python 2.5 release: 31.0s
>
Steve Holden wrote:
> you should diff your source against the current
> SVN repository and lodge that diff as a patch on SourceForge.
Okay, I'll try to do that today.
> Your suggested bug isn't, I think a real bug in the current
> implementation because as I understand it Python strings do alwa
Carl Friedrich Bolz wrote:
> Robin Becker wrote:
>> Larry Hastings wrote:
>> __
>>> THE PATCH
>>>
>>> The core concept: adding two strings together no longer returns a pure
>>> "string" object. Instead, it returns a "string concatenation" object
>>> which holds references to the two strings bu
Robin Becker wrote:
> Larry Hastings wrote:
> __
>> THE PATCH
>>
>> The core concept: adding two strings together no longer returns a pure
>> "string" object. Instead, it returns a "string concatenation" object
>> which holds references to the two strings but does not actually
>> concatenate
>
Robin Becker wrote:
> Larry Hastings wrote:
> __
>> THE PATCH
>>
>> The core concept: adding two strings together no longer returns a pure
>> "string" object. Instead, it returns a "string concatenation" object
>> which holds references to the two strings but does not actually
>> concatenate
>
Robin Becker wrote:
> Larry Hastings wrote:
> __
>> THE PATCH
>>
>> The core concept: adding two strings together no longer returns a pure
>> "string" object. Instead, it returns a "string concatenation" object
>> which holds references to the two strings but does not actually
>> concatenate
>
Robin Becker wrote:
> Larry Hastings wrote:
> __
>> THE PATCH
>>
>> The core concept: adding two strings together no longer returns a pure
>> "string" object. Instead, it returns a "string concatenation" object
>> which holds references to the two strings but does not actually
>> concatenate
>
28 Sep 2006 19:07:23 -0700, Larry Hastings <[EMAIL PROTECTED]>:
> THE BENCHMARKS
>
> Benchmark 1:
> def add(a, b, c, ... t): return a + b + c + ... + t
> for i in range(1000): add("aaa", "bbb", "ccc", ..., "ttt")
[snip]
What about "a + b"? Or "a + b + c"? Does it have a large o
Larry Hastings wrote in news:1159495643.213830.289620
@m7g2000cwm.googlegroups.com in comp.lang.python:
> _
> THE PATCH
>
> The core concept: adding two strings together no longer returns a pure
> "string" object. Instead, it returns a "string concatenation" object
> which holds referenc
Larry Hastings wrote:
__
> THE PATCH
>
> The core concept: adding two strings together no longer returns a pure
> "string" object. Instead, it returns a "string concatenation" object
> which holds references to the two strings but does not actually
> concatenate
> them... yet. The strings ar
Larry Hastings wrote:
> This is such a long posting that I've broken it out into sections.
> Note that while developing this patch I discovered a Subtle Bug
> in CPython, which I have discussed in its own section below.
>
[...]
> __
> THE SUBMISSION
>
> I don't know the protocol from
This is such a long posting that I've broken it out into sections.
Note that while developing this patch I discovered a Subtle Bug
in CPython, which I have discussed in its own section below.
THE OVERVIEW
I don't remember where I picked it up, but I remember reading years
ago that th
35 matches
Mail list logo
