MemoryInfra: Introduce profiling mode in tracing |
||||||
Issue descriptionBackground context:go/memory-infra: memory profiling in chrome://tracing Heap profiler relies on pseudo stack traces. Problems: 1. The number of trace events are too many to run heap profiler with all categories. 2. TraceLog allocates memory for tracing which are counted under memory usage of a function. 3. Huge traces with lot of trace events cannot be opened by trace viewer. Out of memory while profiling too. It is also difficult to understand memory usage without enabling as many categories as possible. We need a profiling category in tracing which just keeps track of pseudo stack traces and not add trace events.
,
Mar 28 2016
I think that problem #2 is separate from #1 and #3. I.e. we need something to prevent trace_event-related stuff from hitting MallocDumpProvider. As for profiling category - why not make "memory-infra" that category? E.g. instead of reporting pseudo stacks from AddTraceEventWithBla function, we move it up, to the macro level? That way it won't depend on other categories.
,
Mar 28 2016
Yes, what you say is true. Adding this mode only reduces the noise in measurements, not eliminate it. But this mode solves problems #1 and #3. Heap profiler also does not require startup tracing anymore. Tracing at any point would give all the information possible. Yes I have drafted a patch that does the macro level changes that you mention. https://codereview.chromium.org/1837013003
,
Mar 29 2016
,
Apr 1 2016
#1-3 should be solved by the tracing refactoring we're going to do as part of ChromeTAP [1]. I think the real question is: do we need any shorter term solution why we get there? Let's discuss in the next meeting. Until we get there, I do realize that #1-#3 are all big problems [1] https://docs.google.com/document/d/1EP9P2dm66V7SiNHWty_cIiyeq3ooKcpTRMgpztlRCCk/edit
,
Apr 5 2016
Hmm ChromeTAP would definitely help here. Sounds like we should just wait for it instead of having a short term solution.
,
Apr 15 2016
I think that trace pre-filtering (which is going to be required even with ChromeTap) is a good intermediate solution we can leverage. Doc: https://docs.google.com/document/d/1S-6OTb4vRAbpZrDQapRytbPEKGoCrkQ6ROApR1Bavnk/edit#
,
Aug 26 2016
https://codereview.chromium.org/2259493003 landed. This issue is fixed.
,
Sep 12 2016
,
Jan 4 2017
|
||||||
►
Sign in to add a comment |
||||||
Comment 1 by ssid@chromium.org
, Mar 28 2016