[Python-ideas] fnmatch.filter_false

[Pavol Lisy]

On 5/21/17, Steven D'Aprano <steve at pearwood.info> wrote:
> On Sun, May 21, 2017 at 08:04:04AM +0200, Pavol Lisy wrote:
>
>> If fnmatch.filter was written to solve performance, isn't calling
>> _filtered step back?
>
> It adds overhead of *one* function call regardless of how many
> thousands or millions of names you are filtering. And the benefit is
> that filter() and filterfalse() can share the same implementation,
> without duplicating code.
>
> If you have a tiny list, then it might be a tiny bit slower, but we
> shouldn't care too much about the performance for tiny lists. We
> should care about performance for large lists, but for large N the
> overhead of one extra function call is insignificant.
>
> At least... I hope so. If somebody demonstrates an actual and
> significant performance hit, then we should rethink the implementation.
>
> But even a small performance hit is acceptible, if it comes with a
> significant benefit (no need to duplicate code) and it is small enough.
>
> On my computer, using Python 3.5, I get little significant difference:
>
> # original
> [steve at ando ~]$ python3.5 -m timeit -s "from fnmatch import filter"
> -s "L = list('abcdefghi')" "filter(L, 'b')"
> 100000 loops, best of 3: 11.7 usec per loop
>
>
> # patched
> 100000 loops, best of 3: 12.8 usec per loop
>
> Who cares about 1 millionth of a second? :-)

I was reading 9-10% slowdown. :)

It could be really good improvement if you can run 110m hurdles in
11.7s instead of 12.8s (nice coincidence ;) that according to wiki -
12.80s is current world record:
https://en.wikipedia.org/wiki/Men%27s_110_metres_hurdles_world_record_progression
)

But I really agree with this:

> But even a small performance hit is acceptible, if it comes with a
> significant benefit (no need to duplicate code) and it is small enough.

although I was rather thinking about something like macro...

PL.