search

ThinkOpenly / self-profiling

A simple API for performance self-profiling code
Other
1 stars 1 forks source link

Would it be good to create a library object and use `LD_PRELOAD` to support self-profiling? #1

Open yskelg opened 2 months ago

yskelg commented 2 months ago

Wow, This is really great Idea. Thank you for the inspiration @ThinkOpenly.

Using LD_PRELOAD to execute at the start with constructor and terminate at exit would be very convenient for profiling other program! If we consider the interface of that library, we could also measure specific functions.

ThinkOpenly commented 2 months ago

Wow, This is really great Idea. Thank you for the inspiration @ThinkOpenly.

I'm pleased that you like it!

Using LD_PRELOAD to execute at the start with constructor and terminate at exit would be very convenient for profiling other program!

Are you suggesting creating a library to be pre-loaded with a constructor that implements PROFILE_BEGIN and a destructor that implements PROFILE_END? That could work, but the constructor should set a flag that the other API methods would need to check every time, just in case LD_PRELOAD was not specified. This adds a bit of additional overhead.

Do you see significant advantage to using LD_PRELOAD in place of PROFILE_BEGIN/PROFILE_END?

If we consider the interface of that library, we could also measure specific functions.

Tell me more about what you are suggesting here.

The current implementation requires that the code to be profiled be instrumented with PROFILE_START/PROFILE_STOP. Are you suggesting there is a way to avoid having to instrument/compile/link by using LD_PRELOAD?

yskelg commented 2 months ago

Thank you @ThinkOpenly for your comments, which have helped me to articulate the self-profiling project more clearly.

One of the key strengths of this project, in my opinion, is the ability to focus profiling specifically on the code where it's needed most.

As you know, If used alongside production code, I believe we can divide the activation into macros and build options—similar to how static trace points are activated with ftrace in the Linux kernel.

This project has reminded me of the importance of understanding the underlying principles to explore new approaches, rather than always relying on existing tools passively.

Do you see significant advantage to using LD_PRELOAD in place of PROFILE_BEGIN/PROFILE_END?

I think my focus is on portability with other executable program. My PR is a Proof of Concept based on what I’ve implemented so far, and I’m happy to update it with any additional ideas you might have. In #2 , I implemented the ability to measure the original main function.

Are you suggesting there is a way to avoid having to instrument/compile/link by using LD_PRELOAD?

If there’s a specific function the user wants to profile, similar to the main function in self-profile.c, this implementation allows for that. I focused on the reusability of the main function for now.

P.S. If there are any additional features you'd like to see implemented, please feel free to open an issue or leave a comment.

Once again, thank you for the inspiration.