> If you fall on a "real" interval, there is no additional queries. If > you fall on a null interval, you have to do one additional query, to get the > previous interval. If you want to query a range, you have to do 2 > queries already, by definition. So in the worst case, you end up doing 4 > queries I don't think this is a big problem from a > performance point of view (especially since those intervals are > close, > they will be close in the history backend, perhaps even in the same > block, in which case it doesn't even have to go to the disk). > instead of 2.
Let say you have 1K processes. There would be 4 (on a 4 core) with a non null value and the remaining 1K - 4 with null values and thus requiring more queries. Furthermore, normally you could do a query for the full state at t0 and t1 to have in a single query the values for the 1K processes. In the other case, you need to do 2 queries for t0 and t1, and 1K - 4 additional queries at different times. The result is therefore more like 2 queries versus 2K queries... These queries could be close and small in many cases but it could also be that each pixel represents a long period and queries are still in different disk blocks. If you change your convention, nulling the value for currently executing processes, the penalty will be much less. Nonetheless, I still have the impression that the more straightforward method, similar to what is used in the kernel to accumulate time usage (cumulative time and start time for the ongoing interval) would be both efficient and easier to understand / maintain. > An interesting point with the proposed method is that we already store > the status of each process in the standard kernel state system, that can > indicate if the process was on or off the CPU at any given time. So we > could avoid duplicating this information. Good! > I think there's a bug with zimbra. Probably very much more than one :-(, sorry about that. _______________________________________________ linuxtools-dev mailing list linuxtools-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
