Re: slow startup on windows

Results are in:

I couldn’t get your timing method to work so I used: std::chrono::high_resolution_clock

I did each 5 times to get a better value:


In release mode in Windows (old way, using append()):

Delta t2-t1: 6057143800 nanoseconds
Delta t2-t1: 6418672700 nanoseconds
Delta t2-t1: 6489762500 nanoseconds
Delta t2-t1: 5962310600 nanoseconds
Delta t2-t1: 5934847700 nanoseconds


New way (pre-allocating 100 elements more than the required array size and removed any used needed elements afterwards):

Delta t2-t1: 1073119800 nanoseconds
Delta t2-t1: 1004918400 nanoseconds
Delta t2-t1: 1026997600 nanoseconds
Delta t2-t1: 1014355300 nanoseconds
Delta t2-t1: 1041731000 nanoseconds


Basically, I went from 6 seconds to 1 second....a very nice speed-up for 2 hr work...


Thanks for the help!!!


I still don’t understand why Windows append is so much slower than on Linux & OSX...I guess it's one of life mysteries...





-----Original Message-----
From: Jeroen van der Zijp <[email protected]> 
Sent: Monday, October 28, 2024 12:36 AM
To: John Selverian <[email protected]>; FOX Users <[email protected]>
Subject: Re: [Foxgui-users] slow startup on windows

On Sun, 27 Oct 2024 15:50:32 -0400
John Selverian <[email protected]> wrote:

> In my case I’ll just over estimate by 100 then erase the unused ones 
> when I know the exact number. I’ll try it out tomorrow and let you 
> know the speedup

I'm curious what the "doubling" algorithm does, too.

To micro-benchmark, please try the new FXPerformance tick-counter based bench-marking support.

How it works:

  1) make sure you pass -DPERFORMANCE_LOGGING=1 on compile line,
     or set it "by hand" in one of your header files.

  2) Make a global variable:

       PERFORMANCE_RECORDER(my_routine);

  3) In your routine:

       PERFORMANCE_COUNTER(my_routine);

Whenever control enters scope containing PERFORMANCE_COUNTER, it logs the processor tick count.  Likewise, when it leaves, it marks the tick count again, and tallies the difference using PERFORMANCE_RECORDER.

The tick counter is a register inside the CPU which increments every clock cycle.  So, its very accurate measure of figuring how fast some code fragment performs.

At the end of your program, PERFORMANCE_RECORDER's destructor will run, which will print how long it took averagely, the maximum, minimum, and total number of times it was called.

W/o the PERFORMANCE_LOGGING preprocessor variable, the macros compile to nothing.

Needless to say, adding the measurement code slightly slows down the code as the bookkeeping adds a minor overhead.  So the total is not entirely cycle-accurate [plus, transitional effects like caching and so in will never quite get you the exact same cycles even if the overhead were 0].  

Nevertheless, if you're doing something that improves your code in even a minor way, you'll see it quickly.

I have used these macros for quite a while; the tick-counter really can help if you absolutely need to trick out and scrape the bottom of the barrel of performance.  

For example, rearranging some heavy-duty floating point code in a higher-order numerical integration routine; I can see the effect of re-arranging the fp code such that the second AVX pipeline can get fully exercised; almost 2x boost was possible on my CPU with just a bit of shuffling bits of code.


   Hope this helps,


            -- JVZ



_______________________________________________
Foxgui-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/foxgui-users