Marcin Mielżyński wrote:
Marcin Mielżyński pisze:
There's Plethora of Ruby.newString(java.lang.String) uses which end up
try/catch block in Bytelist.plain that can slow down the path by a
good 30%-50% over plain getBytes(). It that still needed ?
(not to mention uses like newString("[") an so on). And they're not
paths that are only used for inspection (though, I can realize an app
that uses (Array, Object, whatever)#inspect and similar heavily)
Marcin
Ah, this in turn begs a question if we still need to cache
java.lang.String in ByteList.toString() method. Yes, it's still used
moderately like for getCanonicalHostName(), etc, but it's no longer used
that match. Java Integration might cache it in it's own layer. Might be
a cause of our perm gen issues. Any thoughts ?
No objects normally on the heap ever make it to perm gen...it's an
entirely separate memory space, as far as I understand it.
That said, caching may be useful, but how useful? Are you looking at
specific benchmarks or just probing for possible improvements?
- Charlie
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
