<cfbolz>
j4at: I'm not completely sure. I would try first to even kill the W_AbstractTuple cases in EmptyListStrategy._extend_from_iterable completely
<cfbolz>
because for small tuples there is a case in the caller of _extend_from_iterable, which is ListStrategy.extend
<cfbolz>
and for long tuples, the generic code path, which ends up in _do_extend_from_iterable is better
<j4at>
cgbolz: From what I remember, removing it completly makes extending tuples with object elements slower.
<j4at>
sfbolz *
<cfbolz>
right, plausible
<cfbolz>
so yes, that means some more complex code is required (the unpackiterable_* and listview_* functions actually will return None for float
<cfbolz>
)
<cfbolz>
None for tuple I mean
<cfbolz>
so moving the tuple case down is not gonna help
<fijal>
cfbolz: I *think* that tuple is a way to say "this is an immutable list" too
<fijal>
which means that people will use it for immutable stuff
<fijal>
(how big you want your immutable things? I don't know)
<fijal>
1024 is not massive though
<cfbolz>
fijal: all good, i'm not against improving some things around them. but before implementing tuple strategies, I'd like to see the benchmarks first ;-)
<fijal>
yeah sure
<j4at>
Well that's out of my league, good luck for whoever tries to fix this.
<cfbolz>
j4at: heh, now I found a truly bad case: s = [1, 6, 3, 1, None]; s[:] = big_tuple_with_ints
<cfbolz>
it's like 25x slower than cpy for me
<j4at>
empty list is x90 slower than cpy :p
<cfbolz>
not so great
<cfbolz>
j4at: would you add it as a comment to your issue?
<j4at>
I'm not sure! You can add it if you want! It's kinda of a duplicate issue because I opened another issue before it about how creating tuples/lists./sets is slower in PyPy.
<cfbolz>
it's all the same pattern, really
<j4at>
tuple(list_int) is O(n^2)
<j4at>
Not important at all. because pypy becomes slower than cpy only after 2^11. Even if you have 2^18 list that's only 4 times slower than pypy
j4at has quit [Ping timeout: 245 seconds]
j4at has joined #pypy
jcea has joined #pypy
j4at has quit [Ping timeout: 245 seconds]
j4at has joined #pypy
Atque has quit [Ping timeout: 268 seconds]
Atque has joined #pypy
tsraoien has joined #pypy
Atque has quit [Remote host closed the connection]
Atque has joined #pypy
jcea has quit [Ping timeout: 272 seconds]
Atque has quit [Ping timeout: 268 seconds]
Atque has joined #pypy
<j4at>
I think I found the actual problem :)
<LarstiQ>
j4at: what is it?
<j4at>
I should test it first. But basically it produces big traces.
<j4at>
and retrace forever
<cfbolz>
j4at: yeah, that's the 90x problem for sure
<cfbolz>
I fixed infinite retracing last year, but seems this case isn't covered by the solution
Atque has quit [Ping timeout: 268 seconds]
Atque has joined #pypy
<j4at>
What doesn't make sense to me is why its producing big traces? That shouldn't happen unless it's unrolling, right ?
<j4at>
I also found out that PyPy doesn't optimize type-homogeneous list comparison unlike CPython!! PyPy is x20 slower than Cpython in list comparison
<j4at>
Cpython is always faster even with tiny lists