Really Long Wait when switching to Introjucer


#1

if (alt-tab from a different program to the introcucer && the introducer has been idle for more than a few seconds)
—> The intruducer takes a really long time to wake up again (i.e. 5-10 seconds).

Does anyone else experience this? I;ve had it with multiple (big) projects and it’s rather annoying…

  • bram

#2

No, haven’t seen that here… Would be intrigued to know what’s going on!


#3

…one thought: when you switch back, it’ll check the timestamps of any open files, to see if they still exist. If some of your files are on a network or slow drive, that could be the delay.


#4

I get this too, on my Macbook. No files are remote.

Bruce


#5

Hey Jules,

none of my files are remote. Do notice that this is a rather large project with a LOT of files in it, more than one using the former Jucer interface building… I do notice that it seems to be worse for large projects and not so bad at all for small ones, so imho the number of files does have something to do with it…

  • bram

#6

It’s most likely to do with it checking the files for changes, but I’ve got some pretty large projects myself and haven’t noticed it. Hmm.


#7

I could try to benchmark when I find some time, but that won’t be until quite a bit later… :-S
Could you perhaps point me to what/where I should be looking for the “checking of open files”?

  • bram

#8

Well, there’s a FileModificationDetector class - if it’s spending a lot of time in there, that’d be a clue.


#9

Just to add to the Chorus, I’m seeing the long delays as well on Windows 7 and OS X. Generally it is when it is rendering a complex screen. In my case, I have a screen with two Viewports into other components, and each of those components has between 112 and 150 components, so there are a total of nearly 300 components on screen - it loads very slowly (5+ seconds).

Thank you,

David A. Hoatson


#10

[quote=“David A. Hoatson”]Just to add to the Chorus, I’m seeing the long delays as well on Windows 7 and OS X. Generally it is when it is rendering a complex screen. In my case, I have a screen with two Viewports into other components, and each of those components has between 112 and 150 components, so there are a total of nearly 300 components on screen - it loads very slowly (5+ seconds).

Thank you,

David A. Hoatson[/quote]

Sorry, don’t quite understand what you mean by a “complex screen”… Are you talking about using the introjucer’s GUI builder? That’s a different issue to what the rest of the thread is about, I think, which I assumed was just talking about having a normal project open (?)


#11

Hey Jules,

I don’t know what you call “normal”, but my projects (the ones that take long to load) also have plenty of introjucer/gui components. Now I’m not sure if everything was this slow before the introjucer integration, but the fact that I’m complaining now and not before makes me believe it wasn’t…

  • bram

#12

It could indeed be something in the introjucer, as I don’t use that very much. If it’s taking many seconds, do you have time to catch it in the debugger and see what area of code it’s in?


#13

Jules I just did a test:
as far as I can see it only happens when the curtrently “displayed/open document” is a UI component.

This is what happens in the debugger:

>	Introjucer.exe!juce::TextDiffHelpers::findLongestCommonSubstring(juce::CharPointer_UTF8 a={...}, const int lenA=38271, const juce::CharPointer_UTF8 & b={...}, const int lenB=38427, int & indexInA=6082, int & indexInB=6238)  Line 126 + 0x8 bytes	C++
 	Introjucer.exe!juce::TextDiffHelpers::diffRecursively(juce::TextDiff & td={...}, const juce::TextDiffHelpers::StringRegion & a={...}, const juce::TextDiffHelpers::StringRegion & b={...})  Line 81 + 0x2b bytes	C++
 	Introjucer.exe!juce::TextDiffHelpers::diffSkippingCommonStart(juce::TextDiff & td={...}, const juce::TextDiffHelpers::StringRegion & a={...}, const juce::TextDiffHelpers::StringRegion & b={...})  Line 70 + 0x4b bytes	C++
 	Introjucer.exe!juce::TextDiff::TextDiff(const juce::String & original={...}, const juce::String & target={...})  Line 155 + 0x29 bytes	C++
 	Introjucer.exe!juce::CodeDocument::applyChanges(const juce::String & newContent={...})  Line 591 + 0x2f bytes	C++
 	Introjucer.exe!SourceCodeDocument::reloadInternal()  Line 66 + 0x50 bytes	C++
 	Introjucer.exe!SourceCodeDocument::reloadFromFile()  Line 60	C++
 	Introjucer.exe!OpenDocumentManager::reloadModifiedFiles()  Line 284	C++
 	Introjucer.exe!MainWindow::activeWindowStatusChanged()  Line 271	C++
 	Introjucer.exe!juce::TopLevelWindow::setWindowActive(const bool isNowActive=true)  Line 178	C++
 	Introjucer.exe!juce::TopLevelWindowManager::checkFocus()  Line 77	C++
 	Introjucer.exe!juce::TopLevelWindow::focusOfChildComponentChanged(juce::Component::FocusChangeType __formal=focusChangedDirectly)  Line 167	C++
 	Introjucer.exe!juce::Component::internalChildFocusChange(juce::Component::FocusChangeType cause=focusChangedDirectly, const juce::WeakReference<juce::Component,juce::ReferenceCountedObject> & safePointer={...})  Line 2571	C++
 	Introjucer.exe!juce::Component::internalChildFocusChange(juce::Component::FocusChangeType cause=focusChangedDirectly, const juce::WeakReference<juce::Component,juce::ReferenceCountedObject> & safePointer={...})  Line 2576 + 0x32 bytes	C++
 	Introjucer.exe!juce::Component::internalChildFocusChange(juce::Component::FocusChangeType cause=focusChangedDirectly, const juce::WeakReference<juce::Component,juce::ReferenceCountedObject> & safePointer={...})  Line 2576 + 0x32 bytes	C++
 	Introjucer.exe!juce::Component::internalChildFocusChange(juce::Component::FocusChangeType cause=focusChangedDirectly, const juce::WeakReference<juce::Component,juce::ReferenceCountedObject> & safePointer={...})  Line 2576 + 0x32 bytes	C++
 	Introjucer.exe!juce::Component::internalChildFocusChange(juce::Component::FocusChangeType cause=focusChangedDirectly, const juce::WeakReference<juce::Component,juce::ReferenceCountedObject> & safePointer={...})  Line 2576 + 0x32 bytes	C++
 	Introjucer.exe!juce::Component::internalChildFocusChange(juce::Component::FocusChangeType cause=focusChangedDirectly, const juce::WeakReference<juce::Component,juce::ReferenceCountedObject> & safePointer={...})  Line 2576 + 0x32 bytes	C++
 	Introjucer.exe!juce::Component::internalFocusGain(juce::Component::FocusChangeType cause=focusChangedDirectly, const juce::WeakReference<juce::Component,juce::ReferenceCountedObject> & safePointer={...})  Line 2549	C++
 	Introjucer.exe!juce::Component::internalFocusGain(juce::Component::FocusChangeType cause=focusChangedDirectly)  Line 2540 + 0x2c bytes	C++
 	Introjucer.exe!juce::ComponentPeer::handleFocusGain()  Line 344	C++
 	Introjucer.exe!juce::HWNDComponentPeer::peerWindowProc(HWND__ * h=0x0002060a, unsigned int message=7, unsigned int wParam=0, long lParam=0)  Line 2366	C++
 	Introjucer.exe!juce::HWNDComponentPeer::windowProc(HWND__ * h=0x0002060a, unsigned int message=7, unsigned int wParam=0, long lParam=0)  Line 2212 + 0x18 bytes	C++
 	user32.dll!76c562fa() 	
 	[Frames below may be incorrect and/or missing, no symbols loaded for user32.dll]	
 	user32.dll!76c56d3a() 	
 	user32.dll!76c56ce9() 	
 	user32.dll!76c56de8() 	
 	user32.dll!76c56e44() 	
 	ntdll.dll!7749010a() 	
 	user32.dll!76c578d7() 	
 	user32.dll!76c5790d() 	
 	Introjucer.exe!juce::MessageManager::dispatchNextMessageOnSystemQueue(const bool returnIfNoPendingMessages=false)  Line 107 + 0x10 bytes	C++
 	Introjucer.exe!juce::MessageManager::runDispatchLoopUntil(int millisecondsToRunFor=-1)  Line 116 + 0x10 bytes	C++
 	Introjucer.exe!juce::MessageManager::runDispatchLoop()  Line 98	C++
 	Introjucer.exe!juce::JUCEApplication::main()  Line 246	C++
 	Introjucer.exe!WinMain(void * __formal=0x012e0000, void * __formal=0x012e0000, void * __formal=0x012e0000, void * __formal=0x012e0000)  Line 28 + 0x18 bytes	C++
 	Introjucer.exe!__tmainCRTStartup()  Line 275 + 0x2c bytes	C
 	Introjucer.exe!WinMainCRTStartup()  Line 189	C
 	kernel32.dll!76f833aa() 	
 	ntdll.dll!774b9ef2() 	
 	ntdll.dll!774b9ec5() 	

While it’s being slow.

  • bram

#14

Ah, it’s the TextDiff… I had my suspicions about that algorithm, it can probably go a bit off the rails in complexity if the input is very large. I bet you’ve got some embedded binary resources in the file?


#15

I wanted to run it in the performance wizard which made me remember that the “release mode” flags in the introjucer’s vs2010 project are incompatible with the performance wizard. Don’t have time to research further. I had one resource in there, but it wasn’t a big one. Removed that resource and same performance hogging still happens. I do have to say that the component CPP I’m working on right now is (introjucer metadata included) 2077 lines long. :smiley:

  • bram

#16

PS: https://code.google.com/p/google-diff-match-patch/


#17

Jules,

any chance you will look into this?
as it is the introjucer is really unusable for me…

  • bram

#18

Try it now, I’ve put a limit on the time that the TextDiff algorithm can take to run.


#19

Would this have some weird results when changing/editing files? I.e. might the rest of the app not know that files have changed?

  • bram

#20

No, it should still work the same.