Deleting tasks in liblarch takes a lot of time and hangs the ui

[Luca Invernizzi]

 .

[Thibault Févry (thibaultfevry)]

 I think I've a fix for this.

 Removing tasks in my test version takes : "DELETING 200 NODES: 0.045737".

 I found with profiling that the function that took the most time was: reordered of module of tree_testing.py (14 sec. on my pc.)

 So I think I removed the need for this, my code passes all tests (Except the one for date, because my locale is french.), and I was able to remove tutorial taks. (This means a task with children). I've no idea how I can further test this, so I'm attaching a patch, that would be better to try in another branch to avoid my other error. (With dates.py)

 Posting patch in 2 mins.

[Thibault Févry (thibaultfevry)]

 This is it :D

 Hope I made no mistakes with this, as I already said, try this in a separed branch before.

[Thibault Févry (thibaultfevry)]

[I was running latest liblarch_rebased version, I don't know how it works with trunk.]

[Thibault Févry (thibaultfevry)]

 Not sure about this, but was my patch comitted ?

 Because I don't see the change in test_liblarch.py and removing a high number of nodes is still very slow.

 I'm just wanting to understand this. IS it because the issue is not fixed in the programm, just in the tests ? So why put this as Fix comitted ?

[Luca Invernizzi (invernizzi)]

I set it to fix committed before writing the test_speed Test, after fixing a problem which caused huge delays after each deletion.
The performance issue was found later (it should be a different bug, but we can reopen this too).

Your fix has not been committed because it fixes the testcase, not the problem. The test was written to evaluate the worst case about deletion. If you use the "reverse" function, you change the situation into the best case. I completely agree that the issue is not visible anymore in the tests, but it's still there.

[Thibault Févry (thibaultfevry)]

Oh, ok, but then this test is a bit strange...

 It's all about the worst case, but if this case never happends (Imagine all other calls to remove where with reversed lists), this test would show stupid results, no ?

 I suppose that find the places where remove is used and just add a reverse() call would be enough...

 Because now the only thing that the test does is a benchmark... (At least if I understood well).

 If you want to talk about this without letting too much comments, I'm on irc right now.