The main differences of my solution compared to KCachegrind are: I would use a database approach allowing to display performance history. I.e. in the case of a drop in performance, a developer would be able to localise it to a certain commit. Also useful for comparing the performance of two different solutions during development. The aggregation of counter, IMHO is very important for understanding what the processor is doing. It is a very difficult task, and just having data from 2-8 counters is like providing only a small window on a big complex image. I think that you could summarize kcachegrind as a tool that shows you all the data whereas the approach I propose is to show as little data as possible in order to localise performance issues and when found showing the full image of what the processor is doing. IMHO KCachegrind is not easy to use nor understand (ex: what does "Distance 6-11 (6)" mean? etc...) My solution is web based. I believe that this is enough of differences to justify a new tool. Is it to you? Henrik 2009/6/17 Boudewijn Rempt <boud@xxxxxxxxxxx>: > On Wed, 17 Jun 2009, Henrik Akesson wrote: > >> I propose to implement a tool that allows the user to (step 1) select >> the data he is interested in and (step 2) presents the results in a >> easy-to-understand way. > > Doesn't kcachegrind provide all of this for you? > > Boudewijn > > _______________________________________________ Gegl-developer mailing list Gegl-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
