views:

252

answers:

6

I have a semi big Java application. It's written quite poorly and I suspect there are quite a lot of simple things I can do that will clean things up a bit and improve performance.

For example I recently found the

String.matches(regex)

function used quite a lot in loops with the same regex. So I've replaced that with precompiled Patterns. I use FindBugs (which is great BTW) but that didn't spot this problem and I'm limited on tools that I can use here at work.

Is there anything else simple like this that I should look at?

+5  A: 

Have a look at these differents tools:

I suggest also to have a look at Sonar, which is a great wrapper for all these tools.

All these tools are free!

Globally, they will not help you to improve the performance, but the quality of the code.

romaintaz
+1 for using both PMD and Findbugs
matt b
I have actually used Checkstyle and PMD on my codebase. But I didn't mention it because they do not spot my example problem (Checkstyle moans about whitespace a lot! PMD about System.out etc!). Sonar looks nice, thanks, but I don't have that available to me here.
graveca
+5  A: 

First of all make it a well written application. In my experience most of the performance benefits will come not doing stupid things, rather than doing clever optimisations.

When you have a well written application, then is the time to run a profiler and optimise only that which matters.

Tom Hawtin - tackline
+4  A: 

Is performance an issue? If so, I wouldn't redo anything until I'd profiled the code under a wide variety of conditions and had some hard data in hand to tell me where time was being spent. You might be changing things that have no benefit at all.

I'd be concerned about thread safety. How much attention was paid to that?

If you're going to refactor, start by writing JUnit tests first. It'll help familiarize the code and provide you with a safety net. Tests must pass before and after your changes.

Most importantly, don't undertake a big refactoring just because you consider it a mess. Your team and customer should be on board with what you're doing before you start. Have you communicated your (admittedly good) ideas to others? Software is a team sport; communication is key.

duffymo
Hi. Thanks. Yes performance is an issue; have good unit tests; have team support. Of course, it is difficult not to rewrite the code but I will sit on my hands! This is more about correcting the code - recompiling Pattern each time is just wrong (and slow) - rather than reorganisation.
graveca
agreed, but what you don't know is whether the pattern problem is a significant contributor to the performance issue. data's better than guessing. i'd recommend being as scientific and diligent as you can. i'll make your argument to teammates and customers stronger to be able to point to data.
duffymo
+1  A: 

One very important thing to do when refactoring to improve an application is to first refactor the code so that the source looks at least decent. After that's done, never guess where to optimize, always measure where the bottlenecks are and concentrate on solving those problems. Generally, programmers like to do things such as exchanging recursive methods for loops, choosing the exact correct sorting algorithm, etc., which very often makes very little difference at all. So make sure to focus on the correct area (using too much CPU? Memory? Too many threads? Long thread locks?)

EDIT: Like one of the other posters wrote, of course make sure that others on your team/your boss consider this work worth doing as well, if it's not an issue for them, they could probably care less.

Stefan Thyberg
A: 

Run the code through a profiler (check both speed and memory). Once you find where it is slow (usually not where you think it is) figure out what you can do to speed it up.

Another useful thing (if you are a little brave) is to use NetBeans 7.0 M2 (don't be too panicked, their non-release version are generlaly very stable) there is a plugin called "Jackpot" which searches your code for refactorings. Some of them have to do with performance... but I don't think any of them are going to make a radical change in speed.

Generally speaking, keep the code clean and easy to read and it'll be fast. When it isn't fast you will ahve an easier time speeding it up than if it is mess.

What I did one time when I was writing something that I knew had to be fast (it was code to parse classfiles) is to run the profiler each time I made a change. So for one step I thought I would reduce memroy by calling String.,intern to make sure that all of the Strings were pooled together. When I added the intern() call the memry did go down a bit but the time went up by some huge amount (String.intern is needlessly slow, or it was a few years ago). So at that point I knew that what I had just done was unnaceptably slow and I undid that change.

I don't reccomend doing that in general development, but running the code through a profiler once a day or once a week just to see how things are isn't a productivity killer.

TofuBeer
A: 

If you are into books, I would highly recommend reading Effective Java by Josh Bloch.

Ascalonian
Yes, I love that book! I guess I should read it again.
graveca
Yeah, I love that book as well. It's a staple of mine.
Ascalonian