easy_profiler
easy_profiler copied to clipboard
yse
No MacOS Release Package
Hi guys:
Could you please provide the MacOS release package so that we don't need to build the whole thing? I don't have QT installed on my machine. I guess I can't generate the full binary.
And the other thing that confuses me is the cmake file comes with the package. How should I get those files for MacOS?
I can build the non-GUI version. However, even with QT installed on Mac. I still can't build it.
Hi @JerryCao1985
Sorry for the delay...
We have an idea to grab MacOS artefacts from Travis CI where we are checking our builds, but still we haven't tried this. If you know how to do this easily, you can help us with some instructions :)
As for building profiler_gui on MacOS - is the problem solved now?
If yes then, please, share some info about the issue and the solution at our wiki.
Thank you!
http://45.63.123.194/sort_dependencies/mac/easy_profiler.zip
Here is the link to my pre-compiled one, with GUI interface. I haven't got the Travis CI MacOS artefacets to build the lib. I build it on my own Mac, it works fine, there is nothing quite special.
I just thought that if you faced some problems with building it on Mac, then maybe we should add some fixes to the codebase or docs. If there is nothing special, thats OK :-)
Thanks for the link! Which version have you built? v2.0.1 or latest develop branch, x86_64, x86 arch? Which compiler/glibc version was used?
It lacks necessary Qt binaries though...
I think I will create separate issue for calling MacOS maintainers later to be able to release MacOS builds on regular basis (will try to experiment with Travis first).
I compiled v2.0.1, x64. I can't remember which compiler that I used to compile, I can come back home check and get back to you with the correct answer.
I can check the QT binary also.
BTW, here is my ray tracer project with your profiler fully integrated on all three platforms. I love it. https://github.com/JerryCao1985/SORT
One of the requirement as a user of this tool
Because I am using your tool for profiling in a ray tracer, which is pretty computation heavy. If I place the profiling marker too sparsely, it won't give me anything useful. However, it will most likely stall when dumping files if the marker is on per-ray level because sometimes rendering an image will take billions of rays! It would be good if we could provide a cheaper mode that only generates the percentage of each function without too much cost. Then the tool would be much useful for a ray tracer.
Currently, I can only enable the tool with limited number of rays traced.
Well, yes, it was designed to be used more as continuous profiling tool when you can monitor your frame-rate at run-time and profile the small period of time when things go bad.
30-60 millions of blocks is OK. I have tried to store ~100 millions of blocks, it was quite satisfactorily, but not very good. But billions is too much.
Do you really need to profile the every block of code?
To reduce memory consumption you can disable most of blocks (put profiler::OFF into EASY_BLOCK/EASY_FUNCTION) leaving only top-level blocks enabled and enable them on the need from the UI at run-time.
It seems that you need a sampling profiler here rather than instrumenting one. Sampling profilers were designed to measure hotpaths in general. Intrumenting profilers are more about measuring unexpected hotpaths in continuous processes or measuring concrete blocks of code.
However, adding percentage mode is interesting idea, but I don't think I can handle it in the near future. Unfortunately, I can't give as much time to the project as before.
But it's an open-source, you can become a contributor and help to implement such mode if you are really interested... 😉
@JerryCao1985 by whe way, how do you profile? Do you pofile all rendering process for the whole scene and then trying to dump it to a file? It will be better if you connect profiler_gui to the application and monitor it's FPS and then start profiling if FPS will drop below some acceptable value to search for anomalies. But if your goal is to collect an overall stats and see what you can optimize in general then currently a sampling profiler is the best choise.
Sorry about the delay. Different from real-time rendering, where there is generally less than 1000 blocks in a frame, which is totally not a big deal to your profiler, ray tracer usually needs to trace million of rays ( 1 sample per pixel for a 1080p image is already almost a million, not to mention 1k SPP is very common. ), if not billions of rays. We don't usually talk about FPS in an offline renderer because it is not interactive. I guess you are right, a sampling profiler may be better for a ray tracer project.
Sorry, didn't realized that it is not real-time rendering. Well, however there are profiler::main_thread::frameTime, profiler::main_thread::frameTimeLocalMax, profiler::main_thread::frameTimeLocalAvg functions which can be used to monitor and start/stop profiling programmatically. But it sounds like unnecessary complication though :)