STINNER Victor added the comment: Serhiy Storchaka: "I'm not sure that it is worth to apply this optimization. The patch adds half a hundred lines of complex code for only 80 ns benefit. On my computer just incrementing an integer takes 100 ns."
Yury Selivanov: "(...) Right, but there are so many other things which contribute to the memory fragmentation.. I doubt that optimizing epoll will make any detectable improvement on that side." To be honest, I expected better speedup before I ran the benchmark. That's why I repeat that any performance patch must come with a concrete benchmark showing a non-negligible speedup ;-) I reject my optimization since it doesn't make the code faster. ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26233> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com