Excessive, repetitive, or unnecessary setAccessible calls could impact
performance
----------------------------------------------------------------------------------
Key: JRUBY-4246
URL: http://jira.codehaus.org/browse/JRUBY-4246
Project: JRuby
Issue Type: Bug
Components: Java Integration, Performance
Affects Versions: JRuby 1.4
Reporter: Charles Oliver Nutter
Fix For: JRuby 1.5
>From Toby Reyelts, of the Google AppEngine team:
I've had a few moments to do some measuring on a sample Merb-based webapp that
Ryan Brown gave me a while back. The only test I ran against the webapp was to
load the default page that Merb presents. Some interesting things I see JRuby
doing:
1) Making ~6000 successful setAccessible calls
2) Making ~530 failed setAccessible calls
3) Making ~200 Method.invoke calls
- AccessibleObject.setAccessible calls aren't free on App Engine. (They're not
really slow, but neither are they blazing). Making 6000 of these during startup
is likely chewing up hundreds of milliseconds worth of time.
- Calls to AccessibleObject.setAccessible which fail are currently very
expensive on App Engine - on the order of 50x as expensive. The interesting
part about this is that almost every single one of these calls are against
Object.clone and Object.finalize. Apparently JRuby isn't caching the results,
and for some reason is trying to set them accessible over and over.
- I see that the number of Method.invoke calls is very small compared to the
total number of setAccessible calls. It looks like JRuby is doing something
like eagerly calling setAccessible on every single method of every class that
gets loaded.
It seems like, with some very minor changes, there could be significant
improvements to startup for JRuby on App Engine.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
