[issue13451] sched.py: speedup cancel() method

Change by STINNER Victor : -- nosy: -vstinner ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue13451] sched.py: speedup cancel() method

Change by Serhiy Storchaka : -- pull_requests: +21724 pull_request: https://github.com/python/cpython/pull/22759 ___ Python tracker ___

[issue13451] sched.py: speedup cancel() method

Raymond Hettinger added the comment: I no longer think this should be done. For most applications, cancel() speed is the least important task and isn't worth adding any extra baggage to the run() loop. The current cancel() code is only slow if the length is somewhat large (atypical for a

[issue13451] sched.py: speedup cancel() method

Change by Josiah Carlson : -- nosy: -josiah.carlson, josiahcarlson ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue13451] sched.py: speedup cancel() method

Serhiy Storchaka added the comment: Ping. -- ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue13451] sched.py: speedup cancel() method

STINNER Victor added the comment: I see no possible optimization here. The asyncio was just optimized to handle cancellation of many callbacks, see issue #22448. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13451

[issue13451] sched.py: speedup cancel() method

STINNER Victor added the comment: Serhiy, perhaps it would be useful to see if such optimizations can apply to Tulip's (or asyncio's) event loop, since it will probably be the new standard in 3.4. asyncio was designed differently. Cancelling a task doesn't remove it from a list of pending

[issue13451] sched.py: speedup cancel() method

Serhiy Storchaka added the comment: In updated patch I have reverted queue optimization (this should be separated issue) and made some minor changes. -- Added file: http://bugs.python.org/file32280/cancel_4a.patch ___ Python tracker

[issue13451] sched.py: speedup cancel() method

Changes by Serhiy Storchaka storch...@gmail.com: -- dependencies: -Document that sched.cancel() doesn't distinguish equal events and can break order ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13451

[issue13451] sched.py: speedup cancel() method

Changes by Serhiy Storchaka storch...@gmail.com: Removed file: http://bugs.python.org/file32280/cancel_4a.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13451 ___

[issue13451] sched.py: speedup cancel() method

Serhiy Storchaka added the comment: Fixed a bug in previous patch. -- Added file: http://bugs.python.org/file32281/cancel_4b.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13451 ___

[issue13451] sched.py: speedup cancel() method

Changes by Serhiy Storchaka storch...@gmail.com: -- dependencies: +sched.cancel() breaks events order ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13451 ___

[issue13451] sched.py: speedup cancel() method

Serhiy Storchaka added the comment: All patches have problem with stable order. Rehashifying change it. But there are even more serious problems with current code (see issue19270). -- ___ Python tracker rep...@bugs.python.org

[issue13451] sched.py: speedup cancel() method

Serhiy Storchaka added the comment: Giampaolo, Raymond? What are your opinions? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13451 ___ ___

[issue13451] sched.py: speedup cancel() method

Antoine Pitrou added the comment: Serhiy, perhaps it would be useful to see if such optimizations can apply to Tulip's (or asyncio's) event loop, since it will probably be the new standard in 3.4. -- nosy: +pitrou ___ Python tracker

[issue13451] sched.py: speedup cancel() method

Serhiy Storchaka added the comment: Yes, I will see. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13451 ___ ___ Python-bugs-list mailing list

[issue13451] sched.py: speedup cancel() method

Giampaolo Rodola' added the comment: I don't have time to look into Serhiy's changes right now but here's a brief summary: - there's a (I think) *minor* downside in terms of backward compatibility because scheduler._queue won't be updated after cancel() (basically this is the reason why this

[issue13451] sched.py: speedup cancel() method

Giampaolo Rodola' added the comment: Sorry, I failed to notice there's a scheduler.queue property which exposes the underlying _queue attribute so the patch should take that into account and return the updated list. -- ___ Python tracker

[issue13451] sched.py: speedup cancel() method

Giampaolo Rodola' added the comment: Patch in attachment applies cleanly with the current 3.4 code (last one wasn't) and returns an updated list on scheduler.queue. I rebased my work starting from my original patch (cancel.patch) not Serhiy's because it wasn't clear to me *where* exactly

[issue13451] sched.py: speedup cancel() method

Serhiy Storchaka added the comment: it wasn't clear to me *where* exactly the enter() speedup was introduced Constructing Event object. You introduced __init__(). Here is a patch which is based on my patch and new Giampaolo's patch. In additional it fixes a performance for the queue property

[issue13451] sched.py: speedup cancel() method

Changes by Serhiy Storchaka storch...@gmail.com: -- stage: - patch review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13451 ___ ___

[issue13451] sched.py: speedup cancel() method

Changes by Giampaolo Rodola' g.rod...@gmail.com: -- versions: +Python 3.4 -Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13451 ___ ___

[issue13451] sched.py: speedup cancel() method

Serhiy Storchaka added the comment: In principle this is the right approach. But the time of enter() is increased by 20%. Here is updated and slightly optimized patch that restores enter() performance (but a little slow down cancel()). Because enter() is executed for each event and cancel()

[issue13451] sched.py: speedup cancel() method

Giampaolo Rodola' g.rod...@gmail.com added the comment: Thread locks introduced in issue8684 should make this change more robust. If this patch is reasonable, I'd like to commit it before the one in issue8684 for simplicity. Raymond? -- ___ Python

[issue13451] sched.py: speedup cancel() method

Giampaolo Rodola' g.rod...@gmail.com added the comment: New patch in attachment takes care of modifying empty() and queue property according with the new implementation. With this, the API behaves the same as before (this was my main concern). Also, it's smarter when it comes to cleaning up too

[issue13451] sched.py: speedup cancel() method

Changes by Giampaolo Rodola' g.rod...@gmail.com: Added file: http://bugs.python.org/file23786/bench.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13451 ___

[issue13451] sched.py: speedup cancel() method

Giampaolo Rodola' g.rod...@gmail.com added the comment: In attachment. Before the patch: 9.433167934417725 After the patch: 0.0016150474548339844 scheduler.queue and scheduler.empty should be modified in accordance (which I haven't done, it's just to give you an idea). -- Added

[issue13451] sched.py: speedup cancel() method

New submission from Giampaolo Rodola' g.rod...@gmail.com: snippet # bench.py import sched, time events = [] scheduler = sched.scheduler(time.time, time.sleep) for x in range(4000): scheduler.enter(1, 1, lambda: None, ()) t = time.time() for x in scheduler._queue: scheduler.cancel(x)

[issue13451] sched.py: speedup cancel() method

Raymond Hettinger raymond.hettin...@gmail.com added the comment: Can you post your other patch too? I would like to review both at the same time. -- assignee: - rhettinger components: +Library (Lib) priority: normal - low type: - performance ___