Performance degradation compared to findbugs plugin 2.1

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Minor Minor
  • Resolution: Not A Bug
  • Affects Version/s: 2.3
  • Fix Version/s: None
  • Labels:
    None
  • Environment:
    findbugs-maven-plugin-2.3-20091203.115826-9
    Maven 2.2.1
    Java(TM) SE Runtime Environment (build 1.6.0_16-b01)
    Java HotSpot(TM) Server VM (build 14.2-b01, mixed mode)
    Ubuntu 9.10

Description

I'm experiencing a notable performance degradation from 2.1:
Running mvn findbugs:findbugs with 2.1 on my project takes ~50 seconds.
When I switch to 2.3-SNAPSHOT it takes ~ 1m 20sec

I've measured it several times and always came to the same results.

I don't think that this is because of a performance degradation in FindBugs 1.3.9 'core':
When I use plugin 2.1 and increase the used FindBugs version to 1.3.9, the runtime stays at ~50 secs

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Garvin LeClaire added a comment -

This will be due to the fact that Findbugs is now launched in a forked JVM to support memory configuration and time outs.

Our tests showed increases, but not what you are seeing. Ours were in the range of 10 secs.

Garvin

Show
Garvin LeClaire added a comment - This will be due to the fact that Findbugs is now launched in a forked JVM to support memory configuration and time outs. Our tests showed increases, but not what you are seeing. Ours were in the range of 10 secs. Garvin
Hide
Permalink
Christoph Kutzinski added a comment -

When is the VM forked? Is it forked once per submodule in a multimodule project? That could explain the difference.

If the increase was absolute, I could live with it. But if it is relative to the number of modules and/or classes, it would be a big hurt for big projects.

Show
Christoph Kutzinski added a comment - When is the VM forked? Is it forked once per submodule in a multimodule project? That could explain the difference. If the increase was absolute, I could live with it. But if it is relative to the number of modules and/or classes, it would be a big hurt for big projects.
Hide
Permalink
Garvin LeClaire added a comment -

It is forked for every submodule.

Garvin

Show
Garvin LeClaire added a comment - It is forked for every submodule. Garvin
Hide
Permalink
Grzegorz Slowikowski added a comment -

IMHO forking should be parametrized. It will not be hard to do it. I can provide patch in some days if you agree.

Show
Grzegorz Slowikowski added a comment - IMHO forking should be parametrized. It will not be hard to do it. I can provide patch in some days if you agree.
Hide
Permalink
Christoph Kutzinski added a comment -

> IMHO forking should be parametrized

I think that this is a good idea. I have a project with > 30 submodules. If each forking takes ~10 sec it would mean a runtime increase for findbugs of 5 minutes!

I still wonder why it takes so long for the forking. I always thought that warm-starting a JVM is a matter of a split second.

Show
Christoph Kutzinski added a comment - > IMHO forking should be parametrized I think that this is a good idea. I have a project with > 30 submodules. If each forking takes ~10 sec it would mean a runtime increase for findbugs of 5 minutes! I still wonder why it takes so long for the forking. I always thought that warm-starting a JVM is a matter of a split second.
Hide
Permalink
Christoph Kutzinski added a comment -

I'd like to know, why do you think that this is not a bug?

I've now tested it with a bigger project (multi-module with 30 submodules) and get runtimes of > 8 min (compared to ~4 min with findbugs-plugin 2.1).
I think that this is a rather severe performance regression.

Should I open an enhancement request instead?

Show
Christoph Kutzinski added a comment - I'd like to know, why do you think that this is not a bug? I've now tested it with a bigger project (multi-module with 30 submodules) and get runtimes of > 8 min (compared to ~4 min with findbugs-plugin 2.1). I think that this is a rather severe performance regression. Should I open an enhancement request instead?

People

  • Assignee:
    Garvin LeClaire
    Reporter:
    Christoph Kutzinski
Vote (0)
Watch (2)

Dates

  • Created:
    Updated:
    Resolved: