| commit | 37ac9bc9388e423471dfa1b07c3e4f7e27bca561 | |
| author | strange <kawk256@gmail.com> | |
| Mon, 8 Mar 2010 03:41:42 +0000 (7 20:41 -0700) | ||
| committer | strange <kawk256@gmail.com> | |
| Mon, 8 Mar 2010 03:47:50 +0000 (7 20:47 -0700) | ||
| tree | 6f1f296c61e1666dfc90f6b65898ec3cf895629a | treesnapshot (tar.gz zip) |
| parent | 954a047b112dcd8e34f80071e5ba893f925f8fe9 | commitdiff |
Re-implemented ActiveBlocksRequest to use the new EventVisitor system.
This makes it much more efficient, but means it produces an ActiveBlocksData
instance for each event in the specified time. While nice to have such
accuracy, I think I'm going to have to limit it to ~5000 points of data per
graph . . . it takes far too long and too much memory to display the full
graph for something like fib_test. (~250MB, if you're interested. Not half bad
for 212k events (106k allocations, but reallocations currently count as two
events: a free and an allocation) . . .).
I think the grid might be the next most important thing, as I have mentioned
somewhere in the past . . . I'm not entirely certain how to go about it,
though . . .
This makes it much more efficient, but means it produces an ActiveBlocksData
instance for each event in the specified time. While nice to have such
accuracy, I think I'm going to have to limit it to ~5000 points of data per
graph . . . it takes far too long and too much memory to display the full
graph for something like fib_test. (~250MB, if you're interested. Not half bad
for 212k events (106k allocations, but reallocations currently count as two
events: a free and an allocation) . . .).
I think the grid might be the next most important thing, as I have mentioned
somewhere in the past . . . I'm not entirely certain how to go about it,
though . . .