Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

"Profilers don't help you find memory leaks, they just make your app slower"

plumbr.eu

Post reply on HN
Print view View original

1–10 of 20 posts

Re: "Profilers don't help you find memory leaks, they just make your app slower"

#2

Post by maushu »

What? I'm sorry, but what? The point of profilers is to find memory leaks and performance bottlenecks while disregarding the performance of the app with the profiler running.

Who cares if the profiler is making the app run slower. You aren't going to run it all the time in production!

If you can't find the memory leak or performance bottleneck, either you are doing something wrong or the profiler is not giving enough information. Getting a stack trace of where those byte[]'s are being created would be a good start.

Re: "Profilers don't help you find memory leaks, they just make your app slower"

#3

Post by obtu »

> In all described cases only instructions in "Getting started" or demo video were followed, as every newcomer would do. It is quite possible, that there are some more advanced techniques, which lead to more satisfying results.

From experience in other languages, profilers are perfectly capable of pointing the source of leaks. It's what they're for. They can do so by displaying a weighted object graph (drilling from byte[], in this example, using back references), and by taking stack snapshots of some percentage of allocations.

Re: "Profilers don't help you find memory leaks, they just make your app slower"

#4

Post by daeken »

maushu wrote: post #2

What? I'm sorry, but what? The point of profilers is to find memory leaks and performance bottlenecks while disregarding the performance of the app with the profiler running. Who cares if the profiler is making the app run slower. You aren't going to run it all the time in production! If you can't find the memory leak or performance bottleneck, either you are doing something wrong or the profiler is not giving enough…

This was my thought as well. While memory profilers tend to be fairly useless in my experience, disregarding them simply because they degrade the performance of your application (and really, 3-4x in the case of YourKit is astoundingly good) is silly. Heavy use of a debugger will also degrade the performance of your application -- should we not use debuggers, even when they're the right tool for the job?

Re: "Profilers don't help you find memory leaks, they just make your app slower"

#6

Post by miahi »

You don't have to know only the tools to use, but to know how to use them. Looking only at histograms only tells you what fills the memory, not how it does it. Exploring the object tree in the heap dump and thread dumps are way more useful.

Last month we used VisualVM to get rid of the OutOfMemory errors and to decrease the run time of an application from >110 hours to 40 hours. We found that a big 3rd party library was keeping some kind of undocumented "undo history" of every action, that could not be flushed.

Re: "Profilers don't help you find memory leaks, they just make your app slower"

#7

Post by losethos »

CIA doesn't want people to know what code profiling is. I learned it in a supercomputing class. I was shocked Ticketmaster didn't do it at all.

I don't use the word "profiling" for heap issues.

Ticketmaster did do many performance monitoring things. This was 20 years ago.

Re: "Profilers don't help you find memory leaks, they just make your app slower"

#8

Post by flatline »

maushu wrote: post #2

What? I'm sorry, but what? The point of profilers is to find memory leaks and performance bottlenecks while disregarding the performance of the app with the profiler running. Who cares if the profiler is making the app run slower. You aren't going to run it all the time in production! If you can't find the memory leak or performance bottleneck, either you are doing something wrong or the profiler is not giving enough…

You don't even need a stack trace per se, the profiler should show you where everything is rooted in memory, or you should at least be able to track it back item-by-item to see where they are being held for enough instances to get a general picture of where memory consumption is occurring.
Post reply on HN