TextDiff class

I see this is a new class added. I’m having trouble with it, though i haven’t used it directly i’m getting some serious performance impact with that class. I use a simple Lasso to select some components and display their properties in a PropertyComponent and this takes very long time, i ran profiler on a select/deselect and this is what i’ve got (i’m using ValueTrees for everything and the same static ID stuff that’s used in Introjucer). Is there something new i should be aware and i need to change to make it work properly.


Just to verify i checked out the hash just before the TextDiff class (http://juce.git.sourceforge.net/git/gitweb.cgi?p=juce/juce;a=commit;h=6fb039ba0fd13a9fed5b410d37b35ebf6208a221) and with that code it all works fine.

Sounds like you’re paying for the overhead of some kind of “undo” mechanism on PropertyTree (or PropertyWhatever).

Nope no undos, i haven’t changed my code at all, only JUCE has changed.

Aren’t changes to ValueTrees undo-tracked?

If you pass a pointer to a UndoManager yes, but i pass nullptr everywhere.

Huh? The only place I’ve used the TextDiff class is in CodeDocument. Definitely not involved in PropertyComponents… (?)

Well that might be the case too, cause i’m using a CodeDocument component to display the XML of a ValueTree with the properties (didn’t think this might impact performance, since those trees are small)

Well, you must be hammering its replaceAllContent call, which now uses a diff to only update the bits of text that have actually changed. That method was never really designed for high performance, because I only expected it to be used occasionally, e.g. when a file is reloaded from disk, but I guess I should probably tweak the method to make the diff optional if you want to avoid it.

Maybe not hammering, but yes everytime a selection changes (like in the old jucer) the XML is updated so that it shows the current selection tree. Didn’t think it’s too much really, it worked well before the change.

Sure, I’ll update it.