4 ms·
> Guice may not show up on any profiler as problem The it isn't a problem. > but if you slow down object creation by a factor of 40x, something you may do tho
by gnaritas 12y ago
> Guice may not show up on any profiler as problem
The it isn't a problem.
> but if you slow down object creation by a factor of 40x, something you may do thousands of times per second for the life of your program
Then it'll show up in the profiler. You aren't going to do something that slows down the program across the board yet doesn't create new hot spots that show up in the profiler.
- TheLoneWolfling 12y agoCounterexample: anything that involves cache. You do something that blows away your cache, it'll show up as slowdowns elsewhere in the program.
- gnufx 12y ago> You do something that blows away your cache, it'll show up as slowdowns elsewhere in the program. Presumably that will show up as additional cache misses at those points in the profile, as suggested, assuming the profiler can count more than cycles on the relevant hardware.
- TheLoneWolfling 12y agoUnfortunately, it is really difficult to diagnose cache effects. Do you have a good idea of what levels of cache misses are typical? Do you regression-check cache miss rates between versions? What about the whole "debugging your program makes it slower" observer-effect? Do you know what effect your profiler has on cache? And again, you do something that blows away cache it'll show up as cache misses at scattered random other parts of your problem. Even if you catch it can (will) be hard to track back to the actual source.
- gnufx 12y agoI thought it was regression which was at issue here. I'm not convinced cache is so different from all the other aspects of performance we have to deal with in HPC systems (insofar as they're isolated), but no matter. At least there's plenty of tool support and literature.