Hello, I tried to create a patch for it (this is BlueHazzard's patch in reality). It's my first patch post (and I never worked with svn and so on) so please be tolerant if I did it wrong way.
As stated in the topic this patch is not acceptable. If we're going to add something here we should make this configurable (with formatting like strings)!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
What are the units of time? Seconds, miliseconds, microseconds?
And how do you measure inside codeblocks? Why do you have count=51?
If I'm you I'd measure the impact on the whole statusbar handling. If it is not visibly slower I'll be fine. Also make sure you test with all fields added. :) The whole status bar handling must not be above 1ms or ideally not above 0.1ms.
p.s. If you want to do microbenchmarks, just use a benchmark library like google benchmark.
p.p.s. What is your cpu, just for reference?
Last edit: Teodor Petrov 2019-08-31
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
So new benchmark:
Setup:
I use the same timer function as above from windows, Windows 7 wx302, AMD Phenon X2
I measure the time needed to create the status bar in codeblocks. For this i have to move the mouse cursor and select text. I sample 100 times and print statistical data from them:
Why don't you measure the whole function?
Does it really make a difference? The workload that needs the time (and we want to optimize) is in the time measurement part
Why do you do batches of 100, just calc the stats on the whole sample set.
I do want to mitigate CPU spikes by using batches of the avarage and find and ignore lokal maxima. Also i want to move the mouse only a few times until i see a result...
Are you sure there is no frequency scaling?
Of what? CPU? Can be...
Is everything else stopped (browser, chat, something else)?
No my normal programs are open (Browser, that even takes some CPU in the 5% (thank you fu java script and bloated webpages))
Still 3.6ms is pretty expensive for this function. What is the file you're editing.
Some normal 300 line code... I too think 3.6ms is too much, but i do not notice any slowdown, flashing or other fuzzyness. And my working PC is 10 Years old...
I guess you can push this change and we could optimize it later.
I will experiment a bit and if i do not find any speedup i will push it...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Here is a other idea... No cleanup, and there is still a bug when you change the status bar setting, i just wanted to know if this idea pleases more.
(sadly c++ still does not have fast, typesafe flags...)
Clean up formatting is needed, also probably more encapsulation, but it is to late for this now.... But this concept would add nearly no overhead over the old system...
Ok this is my final proposal.
The performance impact for the default string replacing is minimal. Adding the selection part does slow down a bit, but there is scintilla the slow part. With the implemented flags this does not occure if the selection is not put in the status bar.
i choosed the struct way over the previous type safe flag way for readability... I checked the performace of assambler code and it si as good as it can get when -O3 is enabled...
Hello, I tried to create a patch for it (this is BlueHazzard's patch in reality). It's my first patch post (and I never worked with svn and so on) so please be tolerant if I did it wrong way.
Edit: Corrected one error in the patch.
Last edit: Zdena K 2019-08-25
As stated in the topic this patch is not acceptable. If we're going to add something here we should make this configurable (with formatting like strings)!
Here is a patch with dynamic formatting and nice tags
Can you measure the performance impact of this change? This happens very often and shouldn't add delays to the editor!
Ok, some performance on my pc: All numbers are returned from QueryPerformanceCounter https://docs.microsoft.com/en-us/windows/win32/api/profileapi/nf-profileapi-queryperformancecounter
This is a raw implementation in a new program:
So in the test setup the new implementation is half as fast...
This implementation is in codeblocks under the real code:
so the real impact is low... Good measurement is hard, because my pc is not on idle...
i am not sure why though
What are the units of time? Seconds, miliseconds, microseconds?
And how do you measure inside codeblocks? Why do you have count=51?
If I'm you I'd measure the impact on the whole statusbar handling. If it is not visibly slower I'll be fine. Also make sure you test with all fields added. :) The whole status bar handling must not be above 1ms or ideally not above 0.1ms.
p.s. If you want to do microbenchmarks, just use a benchmark library like google benchmark.
p.p.s. What is your cpu, just for reference?
Last edit: Teodor Petrov 2019-08-31
So new benchmark:
Setup:
I use the same timer function as above from windows, Windows 7 wx302, AMD Phenon X2
I measure the time needed to create the status bar in codeblocks. For this i have to move the mouse cursor and select text. I sample 100 times and print statistical data from them:
And because this is not nice to see i made a plot and attached it
Conclusion, this patch does not make things slower in avarage. The build time is ca 4ms of the whole status bar
Can I see your measuring code? 4ms for statusbar refresh is massive amount of time. :(
calculation of values is not optimized, because it is outside of the time measurement
[edit:] fixed code... had some errors in it
Last edit: bluehazzard 2019-09-03
i forgot to mention: i do compile with -g and no optimization...
[Edit:] With optimization 03 it is not better... avg 3.6ms with patch from top
Last edit: bluehazzard 2019-09-03
If I can say anything to it, it works for me. And I don't see any influence on performance. No measurements, only feeling. Well done, bluehazzard.
Here is a other idea... No cleanup, and there is still a bug when you change the status bar setting, i just wanted to know if this idea pleases more.
(sadly c++ still does not have fast, typesafe flags...)
Clean up formatting is needed, also probably more encapsulation, but it is to late for this now.... But this concept would add nearly no overhead over the old system...
Last edit: bluehazzard 2019-09-18
Does it imporve performance? If it doesn't there is no need for such additional complexity.
Ok this is my final proposal.
The performance impact for the default string replacing is minimal. Adding the selection part does slow down a bit, but there is scintilla the slow part. With the implemented flags this does not occure if the selection is not put in the status bar.
i choosed the struct way over the previous type safe flag way for readability... I checked the performace of assambler code and it si as good as it can get when -O3 is enabled...
What are the numbers?