Re: [ljc] Performance Tuning of a large Method
| From: | robert a. |
| Sent on: | Tuesday, October 23, 2012, 3:30 PM |
Personally I'd refactor the method without worrying about the performance to start with. Instrumenting and inspecting a large method is difficult but if you refactor first (without trying to change any functionality or improve performance) then the problematic part will be much easier to find and test (as per Ben's advice). You might also find that as you refactor it you'll understand what it's doing and the problem may be obvious.
As for what refactoring techniques to use, I'd start with pulling out submethods with distinct functionality in. When your monster method is split into (say) 10 sub-methods I'm betting there will be a single problematic one.
Let us know how it goes!
On Tue, Oct 23, 2012 at 2:44 PM, Ben Evans <[address removed]> wrote:
Hi Craig,
First things first - grab javap and decompile the method.
That way you can see how many bytecodes it's actually turned into.
Next, you should check that it's actually compiling, so use the PrintCompilation flag in UAT (see Stephen's blog article here: http://blog.joda.org/2011/08/printcompilation-jvm-flag.html if you need help driving PrintCompilation) & check that the method is actually compiling.
Next, check that the 185-line monster isn't calling any other methods that may be long-running (e.g. database calls). In short, you need to check that the problem really is where you think it is. You need to know how much of that 40 seconds is intrinsic to the 185-liner. The problem may not be where you think it is.
Next, look at the unit tests. If you don't have any unit tests, you need to fix that issue.
That should keep you going for a bit.
BenOn Tue, Oct 23, 2012 at 2:34 PM, Craig Silk <[address removed]> wrote:
Good morning,I'm working on a rather high trafficked ecommerce platform at the moment where I seem to having some performance issues.I've hooked visualJVM up to the application to find that one particular method is taking over 40 seconds to complete when load is high. Looking at the method, I see it's a 185 line copy and paste job from a legacy codebase that has some rather verbose conditionals and lots of interactions with Collections.I know I haven't given enough information for anyone to really help me but I'm curious as to how you would generally go about dealing with a 185 line, synchronised java method that was lifted out of a legacy codebase. Where am I supposed to begin when refactoring this mess?Craig
People in this
group are also in:
-
Internet of Things London Meetup
14,507 Members
-
GDG Cloud London
8,729 Developers
-
Big Data LDN Meetup
6,623 Members
-
London Scala Users' Group
3,952 Enthusiasts
-
London Software Craftsmanship Community
6,088 Software Crafters
-
Big Data and Machine Learning - London
3,294 Members