[Libreoffice] XMutableTreeNode.removeChildByIndex () hangs up

[Michael Meeks]

Hi there,

On Mon, 2011-05-16 at 13:40 +0400, LRN wrote:
> in python-uno XMutableTreeNode.removeChildByIndex() takes _seconds_ 
> (sometimes minutes) to remove a node from a tree when the node is not 
> the last in the list of its siblings.

	Wow - what fun :-) how much data do you have in your tree ? Of course,
if we can chose an N^4 algorithm where an N^2 one will do, we usually
have so ... ;-) [ and that is before 'wrapping it in UNO' - which can
often add another O(N) ].

	The impl. is here:

http://cgit.freedesktop.org/libreoffice/libs-gui/tree/toolkit/source/controls/tree/treedatamodel.cxx#n447

	Which clearly has some iteration in (N) to turn the index into a
pointer to the node to remove (hard to avoid), but personally I would
suspect a cascade of broadcast events flowing from that to be the issue
- since you claim it is fast if we remove the last event ;-)

> LO hangs for some random amount of time, fully consuming one CPU core 
> (good thing i have 8 virtual ones...). From the looks of the stack of 
> its only working thread, he spends all its time somewhere in python26.dll

	Oh - well, that is even more fun :-)

> I've had a theory that this is somehow related to garbage collecting and 
> memory references, but was unable to fix this by setting DisplayValue 
> and DataValue to new objects (strings) that are not referenced by 
> anything else.

	Interesting.

> Recursively removing all children of the item (it has some) doesn't hang 
> anything, only removing the root of the branch does.

	Reading the code - it looks like that should be extremely fast and
result in only one broadcast.

> I think i can work around this by clearing the branch root of children, 
> then copying all children of its bottom siblings up, filling the gaps, 
> then removing the last sibling, which will be empty. But that will 
> certainly take a bit more time and might actually be seen by the user 
> (especially onn slow PCs).

	So ... ;-) why is it slow - we need more data. The (very) poor mans
profiling tool is gdb: run the slow thing - hit ctrl-<c> when it is
being slow, and get a full backtrace; type 'finish' until you hit
something that takes a second or two to finish - and ... well ;-) you
got some data.

	Clearly it helps to have your own build of LibreOffice so you have
debug symbols and can get more data. It'd be great to find out what that
shows you - hopefully the problem is in python ;->

	Regards,

		Michael.

-- 
 michael.meeks at novell.com  <><, Pseudo Engineer, itinerant idiot