[issue32534] Speed-up list.insert: use memmove()

Change by Inada Naoki : -- resolution: -> wont fix stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue32534] Speed-up list.insert: use memmove()

STINNER Victor added the comment: This issue is a micro-optimization which is only 1.08x faster: https://bugs.python.org/issue32534#msg310146 Moreover, it seems really hard to measure precisely the benefit on benchmarks. Results seem to not be reliable. I suggest to

[issue32534] Speed-up list.insert: use memmove()

Stéphane Wirtel added the comment: Hi, just a small reminder for this issue because I was reviewing the PR. what is the status? Thanks -- nosy: +matrixise ___ Python tracker

[issue32534] Speed-up list.insert: use memmove()

Change by Jesse Bakker : -- nosy: +Jesse Bakker ___ Python tracker ___ ___

[issue32534] Speed-up list.insert: use memmove()

Jeethu Rao added the comment: It's also interesting that in https://gist.github.com/pitrou/29eb7592fa1eae2be390f3bfa3db0a3a : | django_template | 307 ms| 312 ms | 1.02x slower | Not significant| It seems to be slower and the

[issue32534] Speed-up list.insert: use memmove()

STINNER Victor added the comment: In https://gist.github.com/jeethu/dc0811d415dd6d1a1621761e43842f88 I read: | django_template | 160 ms | 129 ms | 1.24x faster | Significant (t=15.05) | So on this benchmark, the optimization seems significant. But in the same paste,

[issue32534] Speed-up list.insert: use memmove()

Jeethu Rao added the comment: > What is 54640? That's the pid of the process. > I'm interested to know which benchmarks call list.insert() 40k times. The django_template benchmark. -- ___ Python tracker

[issue32534] Speed-up list.insert: use memmove()

STINNER Victor added the comment: > Sure! https://gist.github.com/jeethu/000a2d3ecd9033c0ef51331f062ac294 I don't understand how to read this output. "54640 ins1 called 40050 times" What is 54640? I'm interested to know which benchmarks call list.insert() 40k

[issue32534] Speed-up list.insert: use memmove()

Jeethu Rao added the comment: > > I still think those numbers are misleading or downright bogus. There is no > > existing proof that list.insert() is a critical path in those benchmarks. > Can someone check if these bencmarks really use list.insert() in hot code? If >

[issue32534] Speed-up list.insert: use memmove()

STINNER Victor added the comment: > I still think those numbers are misleading or downright bogus. There is no > existing proof that list.insert() is a critical path in those benchmarks. Can someone check if these bencmarks really use list.insert() in hot code? If

[issue32534] Speed-up list.insert: use memmove()

Antoine Pitrou added the comment: Le 17/01/2018 à 14:36, Jeethu Rao a écrit : > > On the other hand, on the pyperformance comparison I'd posted yesterday[1], > there seems to be an average improvement of 1.27x on the first seven > benchmarks, and the slowest slowdown is only

[issue32534] Speed-up list.insert: use memmove()

Jeethu Rao added the comment: > FWIW, we've encountered a number of situations in the past when something > that improved the timings on one compiler would make timings worse on another > compiler. There was also variance between timings on 32-bit builds versus >

[issue32534] Speed-up list.insert: use memmove()

STINNER Victor added the comment: https://gist.github.com/jeethu/19430d802aa08e28d1cb5eb20a47a470 Mean +- std dev: 10.5 us +- 1.4 us => Mean +- std dev: 9.68 us +- 0.89 us It's 1.08x faster (-7.8%). It's small for a microbenchmark, usually an optimization should

[issue32534] Speed-up list.insert: use memmove()

Raymond Hettinger added the comment: FWIW, we've encountered a number of situations in the past when something that improved the timings on one compiler would make timings worse on another compiler. There was also variance between timings on 32-bit builds versus

[issue32534] Speed-up list.insert: use memmove()

Jeethu Rao added the comment: > Be careful. Moving "l.insert" lookup of the loop might make the code slower. > I never looked why. But Python 3.7 was also optimized in many places to call > methods, so I'm not sure anymore :) Thanks again! Here's a gist without the

[issue32534] Speed-up list.insert: use memmove()

STINNER Victor added the comment: > I’ve run the benchmark that you've suggested with a minor change (to avoid > the cost of LOAD_ATTR) Be careful. Moving "l.insert" lookup of the loop might make the code slower. I never looked why. But Python 3.7 was also optimized

[issue32534] Speed-up list.insert: use memmove()

Jeethu Rao added the comment: Victor: I’m booting with the isolcpus and rcu_nocbs flags, and running pyperformance with the --affinity flag to pin the benchmark to the isolated CPU cores. I’ve also run `perf system tune`. And the OS is Ubuntu 17.10. Thanks for the tip

[issue32534] Speed-up list.insert: use memmove()

Antoine Pitrou added the comment: Ok, I ran the benchmarks here (Ubuntu 16.04, Core i5-2500K, PGO and LTO disabled) and I don't get any consistent speedup, which is more in line with what I was expecting: https://gist.github.com/pitrou/29eb7592fa1eae2be390f3bfa3db0a3a

[issue32534] Speed-up list.insert: use memmove()

Change by STINNER Victor : -- title: Speed-up list.insert -> Speed-up list.insert: use memmove() ___ Python tracker ___