You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Profiling types, profefe-collector accepts with the API requests is a predefined list. That made sense in the earlier versions, when profefe stored different profile types in the dedicated Postgres tables, with different schemas per type.
Currently, all types (expect "trace") are treated equally in all implementations of Storage.
Because the list is predefined, using profefe with languages, that expose different types, seems confusing. For example, the profiler for Node.js provides profiling data for "Wall time" and "Heap". It's not clear for a user, what profiling type they should use when sending the profiles to profefe-collector ("CPU time" shows CPU usage but "Wall time" shows total time). A general suggestion always was to use "other" when in doubt but there could be a better way to handle that.
A possible solution to explore is to suggest annotating the profiles with a "special" label, indicating the actual type of the profile. That is
Profiling types, profefe-collector accepts with the API requests is a predefined list. That made sense in the earlier versions, when profefe stored different profile types in the dedicated Postgres tables, with different schemas per type.
Currently, all types (expect "trace") are treated equally in all implementations of
Storage
.Because the list is predefined, using profefe with languages, that expose different types, seems confusing. For example, the profiler for Node.js provides profiling data for "Wall time" and "Heap". It's not clear for a user, what profiling type they should use when sending the profiles to profefe-collector ("CPU time" shows CPU usage but "Wall time" shows total time). A general suggestion always was to use "other" when in doubt but there could be a better way to handle that.
A possible solution to explore is to suggest annotating the profiles with a "special" label, indicating the actual type of the profile. That is
The text was updated successfully, but these errors were encountered: