From mboxrd@z Thu Jan 1 00:00:00 1970 From: simark@simark.ca (Simon Marchi) Date: Mon, 30 Mar 2020 18:26:57 -0400 Subject: [lttng-dev] babletrace2 graph performance considerations In-Reply-To: References: <9b2fe91b-4f44-3b89-eaf9-98f945384a33@simark.ca> Message-ID: <1cc5fee9-487d-61f5-6376-8b3d40dc47f5@simark.ca> On 2020-03-30 1:30 p.m., Rocky Dunlap wrote: > In my case I have CTF trace where some analyses can be performed on a per-stream basis (no need to mux the streams together).? In this case, I was thinking that it would make sense to thread over the streams.? However, I think can easily do this at a level above the graph simply by creating multiple graphs where each one is handling a single stream.? In my case I am thinking this will be mostly I/O bound, so I'm not sure what kind of payoff the threads will give.? Overall, I just want to make sure that I am not doing anything that would, in the long run, preclude threading/concurrency if it is added to the graph model itself. Creating multiple graphs and handling a single stream in each would work, but each graph would end up reading and parsing the while CTF trace, which is not great. If you streams are in a data file of their own, you could move them to their own directory, each with a copy of the metadata, effectively creating one trace for each. Then create one graph for each trace. I can't really tell you right now how to design your components to work with a future model where there is concurrency, since that model does not exist yet :). Simon