Hi all! I have just used the built in profiling of JRuby in a Ruboto project, and it is great! It did require recompiling JRuby with default profilingMode set to API, so I am still searching for a way to activate this in runtime.
The profiling uncovered that most of the time spent in startup of our application is in checking if a path is a file or directory entry in a jar. I added a simple caching mechanism to avoid reading the jar every time, and got a huge speedup. I am working on a patch for this now to push upstream, but I first would like to get some input on strategies for this. I _think_ JRuby allows for jars to change during runtime and that entries from a jar can be reloaded with different content if the jar has changed. Adding a caching mechanism would either remove this feature, or would have to watch the timestamp/size of the jar and flush the cache when the jar file changes. Is this an acceptable way to go? What do you think? The caching mechanism will have to address multithreading. Either synchronize access to the cache or make the cache thread local. The first will slow down concurrent require calls while the second uses more memory. I am leaning towards keeping only one cache and synchronizing that. What do you think? -- Uwe Kubosch Systems Developer Datek Wireless AS u...@datek.no http://datek.no/ --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
