Brakeman performance

gistfile1.txt

jruby 1.6.5 (ruby-1.8.7-p330) (2011-10-25 9dcd388) (Java HotSpot(TM) Client VM 1.6.0_26) [linux-i386-java]

Single core, no threads, Linux:

jruby 1.6.5:     60.91 user 279.93 system 7:13.53 elapsed 78% CPU
   --server:     60.51 user 175.19 system 4:55.54 elapsed 79% CPU
ruby 1.9.2-p290: 61.11 user 17.47  system 1:31.40 elapsed 85% CPU

Single core, with threads, Linux:

jruby 1.6.5:     60.15 user 281.74 system 6:18.44 elapsed 90% CPU
   --server:     60.13 user 172.11 system 4:51.94 elapsed 79% CPU
ruby 1.9.2-p290: 61.55 user 18.00  system 1:29.63 elapsed 88% CPU

jruby 1.6.5 (ruby-1.8.7-p330) (2011-10-25 9dcd388) (Java HotSpot(TM) Client VM 1.6.0_29) [Windows 7-x86-java]

Dual core, no threads, Windows:

jruby 1.6.5:     5:05.749 elapsed
ruby 1.9.2-p180: 1:06.715 elapsed

Dual core, with threads, Windows:

jruby 1.6.5:     4:58.68  elapsed
ruby 1.9.2-p180: 55.850   elapsed

---

Running tests (cd test; ruby test.rb)

Single core, no threads, $VERBOSE = nil, Linux:

jruby 1.6.5:     7.43 user 2.75 system 0:10.91 elapsed 93% CPU
ruby 1.9.2-p280: 2.97 user 0.55 system 0:04.01 elapsed 88% CPU

Really strange that the system times are so high. That would mean the problem's not in our code but in something system-level we call. Perhaps a really bad implementation of something that hits an expensive system-level call a lot?

Can I see how to reproduce this?

Single core with threads by definition will only speed up blocking operations. That is why there is no improvement. Will triple check on my MAC and give you similar numbers on a large project

@headius thanks for your interest in this. All you need to do is run Brakeman (available as a gem) against a medium/large Rails project if you have one available. The -n option turns off threads.