You gotta ask why you are profiling.
To get general performance measurements.
To find ways to make the code go faster yet.
If the answer is 1, then by all means, run your profiler on the optimized code.
If the answer is 2, then don't. Here's why.
There are two kinds of speedups, the ones you can do, and the ones the compiler can do.
The compiler cannot ...
how can I optimize my program's performance when the relevant profiler does not exist?
By profiling your code yourself. Finding GPU bottlenecks is not particularly difficult.
Assuming you have an inferior version of OpenGL (timer queries are not available), then you do what people have been doing for years: change stuff and see how it works.
There are ...
Your second version looks like an attempt at expanding a for loop, but unfortunately it's entirely inaccurate. The outcome is that it is about as far from "the exact same result" as could be.
It sort of only runs one iteration regardless of the input variables, although within that iteration you're running the "loop body" several times in odd places.
If you want the profiling results to be meaningful, you should use the optimization flags that you intend to use in production.
That said, you can tell most compilers to never inline specific functions. For example, if you use gcc you could mark your label functions with __attribute__((noinline)):
__attribute__((noinline)) int func()
Today, the preprocessing is actually happening inside the compiler (e.g. inside the cc1plus executable started by g++ command). Use g++ -C -E to get the preprocessed form.
Preprocessing and parsing is a well known art, and does not take that much time. However, the standard headers of C++11 (e.g. <vector> or <map>) are pushing a lot of stuff. ...
If you really are using WPF, you should probably look into using the MVVM programming paradigm.
First and foremost, you can easily fix updating the UI with most of the functionality in XAML and C# property bindings.
Second, it offers a really large suite of ways to move functionality and business logic away from UI and presentation.
So, with that in mind, ...
The idea is compelling, but I think it needs some more work to find valid measurements for readability.
To understand a piece of software, you need to understand the complete code dependency tree from the entry point down to the lowest level of your supporting libraries. Of course, reading through the complete tree isn't practical because this easily sums ...
First and foremost, before you deliver anything with telemetry (and performance monitoring uses telemetry) to send the results to your servers, check with your legal team.
Many countries have very strict data collection laws
Outside of that, I ...
If I run more then once the same solution, the execution time will be less and I understand that this happens because some of the data gets cached in the memory hierarchy (ram, or cpu registers etc).
So you should run several times (e.g. run five times exactly the same thing) the same "solution" and benchmark them all. The next question is what timing is ...
t seems as if you're trying to use one timer to measure execution time across three objects? If that's what you're doing, your classes shouldn't know anything about that timer.
Set up a timer in another class, start it, execute your three objects, stop the timer, and see the result. An object should only have its own timer if it's responsible for timing ...
SQLite separates the test files as follows:
The "typical" workload is generated by the speedtest1.c program in the canonical SQLite source tree. This program strives to exercise the SQLite library in a way that is typical of real-world applications. Of course, every application is different, and so no test program can exactly mirror the behavior ...
Maybe something similar to debugging programs without a debugger - relying on console/file logging
Not "something similar", but exactly this. In particular
find some timer or clock function of your environment with a resolution which fulfills your needs
use this to measure the execution time of certain code sections, and write that into a log file
try to ...