Skip to content
This repository

Symbol table can't look up from ByteList directly #300

Closed
headius opened this Issue September 17, 2012 · 1 comment

1 participant

Charles Oliver Nutter
Charles Oliver Nutter
Owner

Currently, when looking up a Symbol using a ByteList (or a RubyString) we still convert to a Java String and then look up with that as the key. This causes creation of at minimum a wasted Java String plus buffers used by JVM internally for transcoding our bytes into String.

We need to improve the Symbol table to support direct lookup with ByteList.

More justification: Rails and other libraries frequently use the form :"foo#{bar}" to generate symbols on the fly at runtime. With no caching or improvements, this creates two Ruby Strings, two ByteLists, a Java String and transcoding support classes even when the symbol exists, depending on what "bar" is (if it is not a String, there's a third String and ByteList created for it). I we can get this down to one ByteList total for all cases where bar is a String, Symbol, or Fixnum, which would cover the vast majority of cases.

Charles Oliver Nutter
Owner

See #301 as well.

Charles Oliver Nutter headius referenced this issue from a commit September 17, 2012
Charles Oliver Nutter Improvements for DStr/DSymbol interpretation for #301.
* Special-case core classes in RubyString.append19 to avoid
dyncalls and transient objects.
* Special-case core classes in DNode's EvStr handling to use
append19 directly rather than coercing to a throw-away transient
String.
* Don't create a shared string in DNode, since it's a new ByteList
that's almost immediately written to anyway.
* DSymbol knows super will produce a String, so use more direct
path that doesn't immediately convert to Java String. See #300.
9649428
Charles Oliver Nutter headius closed this in 180468e September 17, 2012
प्रथमेश prathamesh-sonpatki referenced this issue from a commit in prathamesh-sonpatki/jruby September 17, 2012
Charles Oliver Nutter Improvements for DStr/DSymbol interpretation for #301.
* Special-case core classes in RubyString.append19 to avoid
dyncalls and transient objects.
* Special-case core classes in DNode's EvStr handling to use
append19 directly rather than coercing to a throw-away transient
String.
* Don't create a shared string in DNode, since it's a new ByteList
that's almost immediately written to anyway.
* DSymbol knows super will produce a String, so use more direct
path that doesn't immediately convert to Java String. See #300.
4a5e311
प्रथमेश prathamesh-sonpatki referenced this issue from a commit in prathamesh-sonpatki/jruby September 17, 2012
Charles Oliver Nutter Improvements for DStr/DSymbol interpretation for #301.
* Special-case core classes in RubyString.append19 to avoid
dyncalls and transient objects.
* Special-case core classes in DNode's EvStr handling to use
append19 directly rather than coercing to a throw-away transient
String.
* Don't create a shared string in DNode, since it's a new ByteList
that's almost immediately written to anyway.
* DSymbol knows super will produce a String, so use more direct
path that doesn't immediately convert to Java String. See #300.
186f89a
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.