Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!newsfeed.xs4all.nl!newsfeed3.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
MIME-Version: 1.0
In-Reply-To: <43ce1b65-9d6d-47dd-b209-9a3bbafc0b8c@googlegroups.com>
References: <mailman.4618.1373613834.3114.python-list@python.org> <571a6dfe-fd66-42cf-92fc-8b97cbe6e9e4@googlegroups.com> <51DFDE65.5040001@Gmail.com> <CAN1F8qUFP3uX57HhiiUPaYqO3h_HiT8Q_YD=vCYky3EAWsdE7Q@mail.gmail.com> <mailman.4666.1373670835.3114.python-list@python.org> <4f1067f6-bc99-42ad-9166-37fb228b90e8@googlegroups.com> <mailman.5094.1374759404.3114.python-list@python.org> <51f14395$0$29971$c3e8da3$5496439d@news.astraweb.com> <mailman.5106.1374766576.3114.python-list@python.org> <51f15e03$0$29971$c3e8da3$5496439d@news.astraweb.com> <mailman.5127.1374808181.3114.python-list@python.org> <8203e802-9dc5-44c5-9547-6e1947ee224b@googlegroups.com> <mailman.5160.1374890711.3114.python-list@python.org> <f4bb2528-930e-4c0a-820e-66f00ac2b5b6@googlegroups.com> <mailman.5188.1374983652.3114.python-list@python.org> <43ce1b65-9d6d-47dd-b209-9a3bbafc0b8c@googlegroups.com>
Date: Wed, 31 Jul 2013 03:27:03 +1000
Subject: Re: RE Module Performance
From: Tim Delaney <timothy.c.delaney@gmail.com>
To: Python-List <python-list@python.org>
Content-Type: multipart/alternative; boundary=001a11c2ea24d9c50304e2bdea2a
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.5329.1375205232.3114.python-list@python.org>
Lines: 87
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:51587

--001a11c2ea24d9c50304e2bdea2a
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 31 July 2013 00:01, <wxjmfauth@gmail.com> wrote:

>
> I am pretty sure that once you have typed your 127504
> ascii characters, you are very happy the buffer of your
> editor does not waste time in reencoding the buffer as
> soon as you enter an =E2=82=AC, the 125505th char. Sorry, I wanted
> to say z instead of euro, just to show that backspacing the
> last char and reentering a new char implies twice a reencoding.
>

And here we come to the root of your complete misunderstanding and
mischaracterisation of the FSR. You don't appear to understand that
strings in Python are immutable and that to add a character to an
existing string requires copying the entire string + new character. In
your hypothetical situation above, you have already performed 127504
copy + new character operations before you ever get to a single widening
operation. The overhead of the copy + new character repeated 127504
times dwarfs the overhead of a single widening operation.

Given your misunderstanding, it's no surprise that you are focused on
microbenchmarks that demonstrate that copying entire strings and adding
a character can be slower in some situations than others. When the only
use case you have is implementing the buffer of an editor using an
immutable string I can fully understand why you would be concerned about
the performance of adding and removing individual characters. However,
in that case *you're focused on the wrong problem*.

Until you can demonstrate an understanding that doing the above in any
language which has immutable strings is completely insane you will have
no credibility and the only interest anyone will pay to your posts is
refuting your FUD so that people new to the language are not driven off
by you.

Tim Delaney

--001a11c2ea24d9c50304e2bdea2a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On 31 July 2013 00:01,  <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:wxjmfauth@gmail.com" target=3D"_blank">wxjmfauth@gmail.com</a>&gt;</s=
pan> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote"><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-w=
idth:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding=
-left:1ex">
<div class=3D"im"><br></div>
I am pretty sure that once you have typed your 127504<br>
ascii characters, you are very happy the buffer of your<br>
editor does not waste time in reencoding the buffer as<br>
soon as you enter an =E2=82=AC, the 125505th char. Sorry, I wanted<br>
to say z instead of euro, just to show that backspacing the<br>
last char and reentering a new char implies twice a reencoding.<br></blockq=
uote><div><br></div><div><div>And here we come to the root of your complete=
 misunderstanding and</div><div>mischaracterisation of the FSR. You don&#39=
;t appear to understand that</div>
<div>strings in Python are immutable and that to add a character to an</div=
><div>existing string requires copying the entire string + new character. I=
n</div><div>your hypothetical situation above, you have already performed 1=
27504</div>
<div>copy + new character operations before you ever get to a single wideni=
ng</div><div>operation. The overhead of the copy + new character repeated 1=
27504</div><div>times dwarfs the overhead of a single widening operation.</=
div>
<div><br></div><div>Given your misunderstanding, it&#39;s no surprise that =
you are focused on</div><div>microbenchmarks that demonstrate that copying =
entire strings and adding</div><div>a character can be slower in some situa=
tions than others. When the only</div>
<div>use case you have is implementing the buffer of an editor using an</di=
v><div>immutable string I can fully understand why you would be concerned a=
bout</div><div>the performance of adding and removing individual characters=
. However,</div>
<div>in that case *you&#39;re focused on the wrong problem*.</div><div><br>=
</div><div>Until you can demonstrate an understanding that doing the above =
in any</div><div>language which has immutable strings is completely insane =
you will have</div>
<div>no credibility and the only interest anyone will pay to your posts is<=
/div><div>refuting your FUD so that people new to the language are not driv=
en off</div><div>by you.</div></div><div><br></div><div>Tim Delaney=C2=A0</=
div>
</div></div></div>

--001a11c2ea24d9c50304e2bdea2a--