Hey Embers,
I need some advice in tracking down a consistent 13 second start-up delay I have with an application I’m building in Cinder.
Here’s what I’ve been able to determine so far:
- It consistently occurs when making a change in the source, compiling a new build and running that new .exe for the first time.
- Re-running that same compiled executable subsequent times does not exhibit the 13 second start-up time. It’s less than 1s on every subsequent run
- None of my (or Cinders) C++ code appears to be executed in that 13 second window as I’ve popped in numerous breakpoints in my custom
prepare()function and Cinder’smain() - At first I thought it might be DLL related. My application depends on ~6 external DLLs so I took the biggest one (
libcrypto) ~2 Mb in side, created a brand new Cinder project, put some calling code in and ran it. Immediate start / boot all the time. I’m guessing it could perhaps still be DLL related, as perhaps the other DLL’s do something upon linkage, but I feel that’s reaching a bit. - Next I thought perhaps the issue was/is me baking in ~90 files into the executable via
CINDER_RESOURCE, so I reduced this amount by half. Appeared to have no impact on the boot up time. - The Visual studio profiler isn’t much help. It doesn’t show any data for the 13 seconds the program takes to start, other than just an empty graph. I’ve tried ‘taking snapshots’ during this boot time to no avail.
I’ve searched the web for advice but haven’t found much in terms of boot/initialization measuring before the first application window ever shows.
I’m beginning to wonder if it’s actually possible to do anything about at this point, or if a large enough application just carries this weight with it. I really hope not, as 10-13 seconds is quite the flow-barrier.
I’m very open to any recommendations as to how to try and pinpoint what the cause might be or if anyone has experienced anything similar.
Cheers,
Gazoo