On Sun, Nov 24, 2013 at 7:53 PM, Terry Brown <[email protected]>wrote:
[Original post]
QQQ
Some other function: The second one is short and faster than the first.
def computeLeadingWhitespaceWidth (s,tab_width):
w = 0
for ch in s:
if ch == ' ':
w += 1
elif ch == '\t':
w += (abs(tab_width) - (w % abs(tab_width)))
else:
break
return w
def computeLeadingWhitespaceWidth2(s, tab_width):
t = s.expandtabs(abs(tab_width))
return len(t) - len(t.lstrip())
I don't know - are such micro-optimizations welcome or just a distraction?
QQQQQ
On Sun, 24 Nov 2013 10:09:53 -0800 (PST)
> wgw <[email protected]> wrote:
>
>
> The benefit of optimizations is always hard to measure, unless you, um,
> measure it. If you know there's a bottleneck that's slowing things
> down and can target that, that's probably going to help. Optimizing
> code that's called very infrequently or accounts for a tiny proportion
> of runtime may not have a noticeable effect.
>
> So then it becomes a questions of clarity and safety. In the tab
> expansion case I guess the simpler version would be clearer - I also
> guess it wasn't used because str.expandtabs because not everyone's
> aware of it, I wasn't.
>
> The safety thing is a question of what the code does. Changes in
> optional plugins are usually relatively safe. Changes in core code,
> particularly load/save have to be approached much more carefully.
> Where possible unit tests can make changes safer.
>
Let me be a bit more blunt than Terry.
The proposed change, though perhaps amusing, is not simply a distraction.
It could be extremely bad, for at least the following reasons.
1. Although you claim that the two pieces of code are equivalent, you have
not proven your claim. A unit test demonstrating that the two pieces of
code are equivalent **for all relevant strings** would be essential.
2. The existing code, though perhaps verbose, expresses an intention. Even
if the second piece of code were faster than the first, it doesn't express
any intention at all.
3. You seem to have no idea whatever that this is fundamentally important
code. If affects Leo's @file read code as well as Leo's import code.
Therefore, any change whatever to this code, no matter how "innocent" it
seems (and the new code is far from an innocent-appearing change) could
damage existing external files.
4. As Terry says, there is no reason to change this particular piece of
code. It is unlikely to be a bottleneck, and even if it were, you would
have to show that the new version was faster than the old.
In short, this change is, at best, irrelevant. At worst, it could
introduce nasty, data-corrupting bugs.
Edward
--
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/groups/opt_out.
