_djbkd has quit [Remote host closed the connection]
_djbkd has joined #jruby
yfeldblum has quit [Remote host closed the connection]
yfeldblum has joined #jruby
camlow325 has joined #jruby
dinfuehr has joined #jruby
camlow32_ has quit [Ping timeout: 250 seconds]
camlow325 has quit [Ping timeout: 260 seconds]
dinfuehr has quit [Ping timeout: 256 seconds]
<GitHub98>
[jruby] bbelleville opened pull request #3290: [Truffle] Allow for lazy parsing (master...minimal-lazy) http://git.io/vsjZR
<GitHub168>
[jruby] bbelleville opened pull request #3291: [Truffle] Canonicalize input file name (master...canonical-filename) http://git.io/vsjWM
dinfuehr has joined #jruby
dinfuehr has quit [Ping timeout: 245 seconds]
mdedetrich has joined #jruby
b_hoffman has joined #jruby
mdedetrich has quit [Ping timeout: 260 seconds]
mdedetrich has joined #jruby
dinfuehr has joined #jruby
subbu has joined #jruby
dinfuehr has quit [Ping timeout: 245 seconds]
_djbkd has quit [Quit: My people need me...]
dinfuehr has joined #jruby
b_hoffman has quit [Quit: b_hoffman]
<rtyler>
headius: I was benchmarking some RSpec tests today with various opttions for jruby, I'm highly confused why passing in invokedynamic=true is slowly on JDK8/JRuby 9k than without
<rtyler>
that's contrary to my understanding of what that functionality provided
mdedetrich has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
_djbkd has joined #jruby
<headius>
rtyler: tests are worst case scenario for every optimization we make
<headius>
they never get hot so they are running interpreted the whole time...and with indy, what does compile doesn't optimize at the JVM level
skade has quit [Quit: Computer has gone to sleep.]
rsim has joined #jruby
skade has joined #jruby
samphippen has joined #jruby
samphippen has quit [Client Quit]
shellac has joined #jruby
samphippen has joined #jruby
shellac has quit [Quit: Computer has gone to sleep.]
<GitHub14>
[jruby-openssl] kares pushed 2 new commits to master: http://git.io/vGeRy
<GitHub14>
jruby-openssl/master 34aaa64 Chris Heisterkamp: add TLSv1_1_client, TLSv1_1_server, TLSv1_2_client and TLSv1_2_server options to ssl_version
<GitHub14>
jruby-openssl/master c3ac283 kares: add some more asserts for reported TLS v1.2 among METHODS (closing #65)
<GitHub182>
[jruby-openssl] kares closed pull request #65: add TLSv1_1_client, TLSv1_1_server, TLSv1_2_client and TLSv1_2_server options to ssl_version (master...add-tls-client-server) http://git.io/vsDsu
sdogruyol has quit [Read error: Connection reset by peer]
<GitHub122>
[jruby] pitr-ch commented on commit 6b0d84b: ah thanks, I did not notice it also uses the type of the annotated argument before. http://git.io/vGvaz
skade has joined #jruby
<GitHub109>
[jruby-openssl] kares pushed 2 new commits to master: http://git.io/vGvrk
<GitHub109>
jruby-openssl/master a20aaa6 kares: add gem 'rake' to integation bundle
<GitHub109>
jruby-openssl/master 81db73b kares: [travis-ci] give `ruby -S rake ...` command another try
shellac has joined #jruby
<GitHub63>
[jruby] chrisseaton pushed 1 new commit to truffle-head: http://git.io/vGvK1
<GitHub63>
jruby/truffle-head 71b600d Chris Seaton: [Truffle] Update for latest Truffle.
vtunka has joined #jruby
<GitHub56>
[jruby] chrisseaton pushed 1 new commit to truffle-head: http://git.io/vGviA
<GitHub56>
jruby/truffle-head b20f3ff Chris Seaton: Merge branch 'master' into truffle-head...
samphippen has quit [Ping timeout: 246 seconds]
sdogruyol has quit [Remote host closed the connection]
<projectodd-ci>
bbellevi: [Truffle] Canonicalize input file name
<GitHub33>
[jruby] eregon pushed 1 new commit to master: http://git.io/vGfDa
<GitHub33>
jruby/master 8470c9c Benoit Daloze: [Truffle] No Java 8 Map.getOrDefault.
enebo has joined #jruby
<GitHub192>
[jruby] carlosmrce opened issue #3292: UTF-8 encoding on MS-Windows http://git.io/vGJJC
<headius>
g'day!
benlovell has quit [Ping timeout: 250 seconds]
<headius>
kares: that's great...we should probably do it along with 9k then
<headius>
enebo: jossl regression is fixed, kares is da best
mdedetrich has joined #jruby
<enebo>
headius: great
mdedetrich has quit [Client Quit]
<GitHub137>
[jruby] eregon pushed 1 new commit to master: http://git.io/vGJmQ
<GitHub137>
jruby/master d2357f3 Benoit Daloze: [Truffle] Finish the conversation to our wrapper of sun.misc.Signal.
<kares>
headius: enebo: ok sure ... when's 9K.1 planned - next week ?
b_hoffman has joined #jruby
<enebo>
kares: How about Monday. I do not want to update this today and release today and I do not like Friday releases
benlovell has joined #jruby
<enebo>
headius: seem ok to you?
<kares>
enebo: exactly ... ok :)
<headius>
enebo: that means we'll ship 9k.1 with damaged jossl
<headius>
oh wait
<headius>
you mean delay 9k.1 to monday
<headius>
ok
<enebo>
yeah
<kares>
will do a jossl release monday than ... if anything regression-y pops up till than - ping me or cc in GH
<headius>
can we push a pre gem right now so we can test with it and give that guy a temp workaround?
<kares>
yes we can do a snapshot
<lopex>
enebo: numbers!
<kares>
and I'll setup staging to run JRuby's suite
<headius>
ok
<lopex>
headius: did you see the mode windows issue for File.open ?
<headius>
I did not
<GitHub58>
[jruby] eregon pushed 1 new commit to master: http://git.io/vGJsb
<GitHub58>
jruby/master c9712e8 Benoit Daloze: [Truffle] Simplify Signal handling by making our wrapper remember the default handler.
<enebo>
lopex: did you see someone opened an issue about not following softlinks on windows!?!?!?
<lopex>
enebo: I heard it's the hard ones that didnt work
<lopex>
enebo: oh you're being serious ?
<lopex>
:)
havenwood has joined #jruby
<enebo>
lopex: The report says softlink but it is actually called a hardlink in their case…but we probably do not support junctions or softlinks either
<lopex>
bbrowning: does torquebox load gems in a different way somehow, I got ptached class in my code and it's not being visible when run on torquebox
<enebo>
lopex: I love how windows takes a common term and changes it to mean something different from all other OSes 30+ years after the old term has been in existence
sdogruyol has joined #jruby
<lopex>
enebo: rewriting the engineering
<bbrowning>
lopex: torquebox 3? we shouldn't be doing anything different
<bbrowning>
torquebox 4 for sure does not
<lopex>
bbrowning: yeah, 3.2 snapshot too
<bbrowning>
lopex: what class are you patching? and how does the patch get loaded?
samphippen has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<lopex>
bbrowning: it's patching some sequel guts (in as400 adapter), in my code that is being loaded after
dinfuehr has joined #jruby
<bbrowning>
lopex: and you confirmed your patched code is actually loading with a puts or something?
<lopex>
bbrowning: TorqueBox 4.0.0.beta1 gem works ok though
<lopex>
bbrowning: yes, definitely confirmed
<lopex>
bbrowning: I'm not sure how to make a reduced case though
<bbrowning>
lopex: are you using sequel from the web runtime here? or via a schedule job, message processors, etc?
<lopex>
bbrowning: no
<bbrowning>
I've seen some users tripped up because config.ru was only loaded for web runtimes and people sometimes put moneky patches there
<lopex>
bbrowning: er, if you mean web as rack the yes
<headius>
enebo: perhaps they're using CP/M terminology :-D
<bbrowning>
lopex: yeah
<lopex>
bbrowning: I'll check that and let you know
<bbrowning>
lopex: torquebox 3 creates separate jruby runtimes for web, messaging, scheduled jobs, etc
<bbrowning>
so you'll want to make sure your patch is getting loaded via some code path that gets executed everywhere you're using sequel
<bbrowning>
that was my only point :)
<lopex>
bbrowning: sequel does a bit of method copying in it's extensions so it might also complicate things
<enebo>
headius: perhaps but even CP/M missed softlinks by about 15 years
<headius>
yeah
dinfuehr has quit [Ping timeout: 260 seconds]
<enebo>
headius: another aspect seems that this link feature only showed up in Vista
<headius>
and links didn't show up in MS operating systems until NT
colinsurprenant has joined #jruby
<enebo>
headius: ah yeah they probably were NT
<headius>
what feature is that? win2k supported ntfs
<enebo>
headius: the article I read just pointed out they used them in earnest since Vista for Document And Settings crdu
greenbigfrog has left #jruby [#jruby]
<headius>
strange, I thought they were doing that magic earlier
<enebo>
headius: I have first hand issues with this in fact. I got my windows machine to back up in win7 over network but I had to manually remove all those links to get the backup to work (limitation of their backup software o_O)
<headius>
oh, lovely
<enebo>
headius: but no doubt this is a NTFS feature
<enebo>
headius: yeah I was wondring how IT in companies backup any machines
<enebo>
headius: they probably nuke all those links as well
<headius>
yeah, wikipedia says NTFS came along in NT 3.1
<headius>
dunno if that first version of NTFS had "hard links" or not
<headius>
the terminology on wikipedia does seem to match unix hard links though
<rtyler>
enebo: that's what gives me the lower end ;)
<enebo>
lower as in slowest of quickest?
shellac has quit [Quit: Computer has gone to sleep.]
<enebo>
of/or
<rtyler>
~26s
<enebo>
ok
<rtyler>
invokedynamic destroys any perf gains
<rtyler>
on openjdk8, which makes me sad
<enebo>
rtyler: so I believe some of this time is that we are stlll not loading Ruby code as fast as in 1.7 yet
<lopex>
enebo: would an external file containing hints for the code to be aot compiled make sense ?
<rtyler>
9k/invokedynamic has an average of 88s runtime compared to 35s on 9k with -dev
<lopex>
like slow initialization containg loops etc
<enebo>
lopex: we have that as a blue sky idea
<enebo>
rtyler: you are not constrainted by execution by and large
<enebo>
rtyler: if our startup interp was a little faster you would see it but the extra IRBuild step is 10-15% of the 1.7 difference
<enebo>
rtyler: possibly more…it is hard to untangle startup execution from build since it all sort of jumbles together
<enebo>
rtyler: so we will keep chipping away at load time
<enebo>
lopex: the idea is that we want to persist later in IR execution at a conservative optimization point and potentially at unsafe but deoptable points
<lopex>
enebo: I know, but there are cases you want to run cold code fast
<enebo>
lopex: saving the data and re-retrieving it will be a big experiment and at this point we only save equivalent of what we call startup interp data
<enebo>
lopex: subbu came up with a brilliant solution for that too
<headius>
slow cold perf with indy is no surprise to me
* subbu
looks up
<enebo>
lopex: we can mmap the persisted IR and make a binary interpreter
<lopex>
enebo: and you'll never have good profile for that
<enebo>
lopex: we will not reify any obkects to start interp'ing
<headius>
it has improved a bit with later Java 8 but it's still takes longer to get warm there than not using indy
<enebo>
lopex: that should be super fast to start executing code but it is unclear how fast it will execute code :)
<lopex>
enebo: you can mmap java heap easily ?
<enebo>
lopex: no..well I don’t know
<lopex>
or just the repr of it ?
<headius>
enebo: I thought of a way to make the handle-based invokers a bit faster: set them up as constant pool entries
<headius>
I think that will make them optimize faster and probably boot faster
<headius>
not sure if it will be able to beat generated invokers though, and I'd have to generate them somewhere
<enebo>
lopex: this would just be walking contents of memory and executing as it sees the bytes
auxbuss has quit [Quit: I'm gone.]
<lopex>
headius: is there in IO a centralized place for windows goofy logic ?
<enebo>
headius: it would be neat to some daty not ship a few thousand extra classes :)
<headius>
we might want to set up handle-based invokers as the default for exts, though, because they should boot faster in that case and mean less class loading
<headius>
e.g. jossl
<headius>
lots of invokers being generated and classloader at boot
<lopex>
headius: like special cases for modes and encodnigs ?
<lopex>
mri is scattered with this stuff :(
<enebo>
lopex: I have always wanted a lookup once pragma in Ruby code so it can be unconditionally wired (and in IR it could auto inline)
<enebo>
lopex: but if that was added it would be abused by people who think inlining their entire program would be good perf
<lopex>
enebo: right, like inline annotations or whatever
<enebo>
lopex: yeah
<enebo>
lopex: not a new or exciting idea but one which could get a lot of perf strategically internally in ruby impld code
<lopex>
enebo: but external file would be more robust
<mjc_>
ouch, indy hurts on 9k, going to give it 1m requests and see if it warms up by then
bbrowning_away is now known as bbrowning
lance|afk is now known as lanceball
<GitHub192>
[jruby-openssl] kares fast-forwarded master from 59347f2 to eab72b8: http://git.io/vGTnW
vmarcetic has joined #jruby
<vmarcetic>
Hi guys. Can anyone help me with no such file to load -- iconv require at org/jruby/RubyKernel.java:940 block in require at /Users/vm/.rvm/gems/jruby-9.0.0.0/gems/activesupport-4.2.3/lib/active_support/dependencies.rb:274
<nirvdrum>
vmarcetic: I think you need to add 'iconv' to your Gemfile.
<vmarcetic>
but when I add it, it won't install it /Users/vm/.rvm/rubies/jruby-9.0.0.0/bin/jruby -r ./siteconf20150827-31021-vqigzf.rb extconf.rb NotImplementedError: C extensions are not supported
dumdedum has quit [Quit: foo]
<nirvdrum>
Okay. Give me a minute. I swear I ran into this situation a year ago.
<vmarcetic>
which iconv /usr/bin/iconv
<vmarcetic>
If I use
skade has quit [Quit: Computer has gone to sleep.]
_djbkd has joined #jruby
<nirvdrum>
This indeed is problematic.
<nirvdrum>
My memory is a bit hazy on this one, but I think I had convinced headius to keep it around. But it was removed almost 2 years ago. Hard to be certain on it.
<nirvdrum>
headius: ^ Any of this ringing a bell?
<vmarcetic>
The problem is that it is one of dependancies on active support 4.2, and server won't start if that isn't resolved. Maybe I have missed something. I have included activerecord-jdbcpostgresql-adapter for PG isntead of pg.
<nirvdrum>
The issue is iconv was dropped from MRI, but MRI users can install the gem.
<nirvdrum>
JRuby users don't seem to have the same luxury.
<vmarcetic>
y
pglombardo has joined #jruby
camlow32_ has joined #jruby
camlow325 has quit [Ping timeout: 240 seconds]
<bbrowning>
vmarcetic: what is it that needs iconv? I don't think it's an active support dependency is it?
<bbrowning>
at least not directly
<bbrowning>
I've hit this before and just assumed that any gem that depends on iconv isn't compatible with ruby 2+
<bbrowning>
active support definitely is, so it's probably something else. your gemfile.lock may help
<nirvdrum>
bbrowning: I just tried against my old Mogotest codebase and I had been using Iconv directly because it handled more encodings than either MRI or JRuby did.
_djbkd has quit [Remote host closed the connection]
<nirvdrum>
It'd probably be worthwhile spinning the old code out into a new gem and calling it a day.
bbrowning is now known as bbrowning_away
_djbkd has joined #jruby
_djbkd has quit [Read error: Connection reset by peer]
<vmarcetic>
Let me check. I was AFK.
benlovell has joined #jruby
_djbkd has joined #jruby
vmarceti_ has joined #jruby
vmarcetic has quit [Ping timeout: 244 seconds]
<vmarceti_>
I can only see it under DEPENDENCIES iconv
<vmarceti_>
that is it
skade has joined #jruby
<GitHub94>
[jruby] kares created test-jossl-0.9.11 (+1 new commit): http://git.io/vGTQv
<GitHub94>
jruby/test-jossl-0.9.11 708a32f kares: [build] test-out jruby-openssl 0.9.11 from staging
subbu is now known as subbu|lunch
benlovell has quit [Ping timeout: 250 seconds]
vmarceti_ has quit []
benlovell has joined #jruby
<lopex>
bbrowning_away: yep, it works in config.ru
<lopex>
but this is somewhat frustrating
pitr-ch has joined #jruby
<rtyler>
enebo: if you and headius are curious about my benchmarking results, I'm sure I can share them privately, but I can't quite share the code under test :P
<rtyler>
I was mostly just comparing various JRuby and VM flags
camlow32_ has quit [Remote host closed the connection]
<bbrowning>
lopex: so your patch is in config.ru now and works fine but was somewhere else before and didn't?
benlovell has joined #jruby
<bbrowning>
wherever it was before, you have absolute confidence that the patch was loading after sequel itself?
<lopex>
bbrowning: never claim absolute confidence! :)
<lopex>
bbrowning: I'll reassure that
<bbrowning>
:)
<lopex>
bbrowning: but for torquebox 4.x beta it works somehow
<bbrowning>
it's vastly different than torquebox 3, especially around how jruby runtimes get created so I'm not surprised
<bbrowning>
torquebox 3 always creates and manages the jruby runtimes where torquebox 4 just runs inside an existing jruby runtime like any other ruby lib
skade has quit [Quit: Computer has gone to sleep.]
flegercovateam has joined #jruby
<GitHub58>
[jruby] mkristian opened issue #3293: jruby gems might not work when using in servlet http://git.io/vGk39
camlow325 has quit [Read error: Connection reset by peer]
camlow325 has joined #jruby
<byteit101>
enebo: fyi i've almost finished re-doing jruby-fxmlloader to not depend on java internal classes. Bonus is its also not GPL+CP anymore. Also now much faster and only about 150 lines of code vs prevous thousands and thousands
subbu|lunch is now known as subbu
_djbkd has quit [Remote host closed the connection]
<lopex>
bbrowning: I guess this explains another issue, since even though I have registered driver in modules and defined connection in standalone.xml I still have to put driver jar in plain old jruby/lib
<bbrowning>
I felt like it was also a bit of blind luck figuring out where to put jdbc driver jars
<bbrowning>
but, $app/lib/foo.jar should work
<bbrowning>
or at least we tried to make that work
dinfuehr has joined #jruby
<lopex>
bbrowning: using jndi kind of forces two places
<bbrowning>
ahh yeah with jndi you have to jump through whatever hoops the underlying app container requires :/
dinfuehr has quit [Ping timeout: 250 seconds]
yfeldblum has joined #jruby
<lopex>
bbrowning: that might be also sequel issue since even it uses jndi it also knows what adapter to use and it appears to do Class.forName anyways
_djbkd has joined #jruby
_djbkd has quit [Read error: Connection reset by peer]
_djbkd has joined #jruby
rsim has joined #jruby
camlow325 has quit []
samphippen has joined #jruby
samphippen has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<byteit101>
enebo: indeed. Now instead of a copy of fxmlloader, it scans the file for fx:is's and event handlers, defines them on a dynamic proxy class which is then become_java!'d, and calls the real fxmlloader
<enebo>
byteit101: neat
<nirvdrum>
headius: Do you have the link for that HotSpot crash in 9k I was supposed to follow up on?
<enebo>
nirvdrum: we were just hanging out so he will probably be home in 20-30 minutes
vyorkin has joined #jruby
<nirvdrum>
That must be nice. I've been working with Chris for almost 10 months and haven't met the guy.
<enebo>
nirvdrum: I have been working with lopex for almost 10 years and he refuses to meet me
<nirvdrum>
Heh.
<enebo>
nirvdrum: hopefully you will be at Rubyconf so we can hang out
<nirvdrum>
I think that's the plan.
<nirvdrum>
Still waiting to hear back on my talk proposal.
skade has joined #jruby
<lopex>
enebo: I dont refuse, I'm in jail
tcrawley is now known as tcrawley-away
<lopex>
bbrowning_away: managed to run that thing in a docker with deployment dir mounted outsite the container
<lopex>
rubygems stalls sometimes in a container, no idea why
drbobbeaty has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
pitr-ch has quit [Ping timeout: 246 seconds]
vyorkin has quit [Ping timeout: 260 seconds]
<nirvdrum>
enebo, lopex: I'm looking at this String#== microbenchmark (in bench9000) that eregon wrote a little while back. JRuby is about 7x slower than MRI.
<nirvdrum>
And indy runs slower than nonindy.
<lopex>
nirvdrum: Charlie's last report might remove lots of optz
<lopex>
nirvdrum: anything shows in the profile ?
<lopex>
nirvdrum: I bet sub/gsub/scan etc are now much much slower
<nirvdrum>
I don't have historical data. And I haven't looked at profiles.
<nirvdrum>
I just ran the bench for the first time and then reran it to be sure.
b_hoffman has quit [Quit: b_hoffman]
<enebo>
nirvdrum: so they are actually the same string but unshared and a million chars long?
<enebo>
err larger
<enebo>
10m
<nirvdrum>
enebo: Yeah.
<enebo>
well I can see one problem immediately
<nirvdrum>
Obviously an extreme.
<enebo>
we count from front and back at same time but go the entire way
<enebo>
so we do 2n compares instead of n compares
vyorkin has joined #jruby
<nirvdrum>
Truffle numbers are roughly the same, with our without Graal, FYI.
<enebo>
which would be only be 2x of the 7x I guess
<enebo>
I wonder why this accesses non-final fields
<enebo>
lopex: yeah it will internally rewrite it
<lopex>
enebo: and yeah, jdk hoists to locals the buffers
<enebo>
lopex: but I mean if it knows it has to stop by 0 it should be able to work out it cannot leave array bounds at a higher level
<enebo>
lopex: oh sorry that was what you mean by hoisting
<lopex>
enebo: afaik from 0 to n also eliminates the bounds
<lopex>
since n is known ahead
<enebo>
lopex: so long as value cannot exceed n
<lopex>
enebo: oh, hmm if you hosit to locals, then the arrays cant change
<lopex>
as well as it's length
<lopex>
so you can eliminate
<lopex>
well, just contemplating
<lopex>
enebo: in old days I was always afraid of too much locals, since the bytecode grew as you added them :)
<lopex>
enebo: but afaik they eliminate on more complex cases, like copying overlapping regions
<lopex>
enebo: wrt that, we also have maybe too smart algo for nil filling in arrays
<lopex>
*might have
<nirvdrum>
I hate the Internet.
<enebo>
lopex: history lost from 2008 when ola moves this to an independent package
<nirvdrum>
Every single time I search for how do something efficiently, the top-voted answer is "did you profile? is this actually a problem?"
<enebo>
lopex: you added otherBuf as local to improve perf which no doubt it a 1.4 improvement
<lopex>
nirvdrum: I hope it's not a problem with cr
<enebo>
nirvdrum: yeah we were talking about this recently that people should not reply if they are not going to answer your question…at least not on ask question sites
<lopex>
enebo: there's also the begin
<enebo>
lopex: begins might also help
<nirvdrum>
lopex: MRI is able to a memcmp, which is presumably faster.
<lopex>
they always cheat
<nirvdrum>
enebo: I was looking to see if there was a memcmp equivalent for Java. The response was something along the lines of "is comparing two byte arrays really a bottleneck in your app?"
<nirvdrum>
As if the guy that's looking for a memcmp equivalent in Java needed a lecture on profiling.
<enebo>
hah
<lopex>
nirvdrum: too bad there's no Arrays.equal with indices, there would be a chance of it being an intrinsic
<nirvdrum>
enebo, lopex: I don't know how much it'll matter, but if begin is the same for both, we could use Arrays.equals()
<nirvdrum>
And I suspect for a lot of strings, begin == 0.
<enebo>
I wonder if bytebuffer.compareTo is native :)
<lopex>
enebo: doesnt have to be native
<enebo>
I somehow doubt calling wrap + native would work
<lopex>
enebo: there's lots of things intrinsicised
<nirvdrum>
I think Arrays.equals may get intrinsified.
<lopex>
though I guess hotspot doesnt go into that nowadays
<lopex>
nirvdrum: oh, right, didnt know how to spell that
<lopex>
and even pronounce
<lopex>
nirvdrum: so a case for 0 ?
<nirvdrum>
lopex: I think it's a made up word, so I wouldn't be too worried about it.
<nirvdrum>
lopex: If they have the same byte[] length and the same begin, I think you could just use Arrays.equals.
<enebo>
nirvdrum: yeah the responses to questions like memcmp is that “The String library has been optimized”…yeah if you want to constantly transcode to utf-16le
<nirvdrum>
Bah, no, it would need to be begin == 0 because there could be junk at the beginning.
<lopex>
yep
<nirvdrum>
Still, I think that's a lot of strings.
<lopex>
worth a try
<nirvdrum>
As long as you didn't take a substring, begin == 0, right?
<lopex>
doh there's still the end :)
<lopex>
it's a bummer there's no Arrays.equals with indices
<nirvdrum>
lopex: Well, that's checkable via bytes.length.
enebo has quit [Quit: enebo]
<lopex>
nirvdrum: otoh intrinsics dont pay of as well as they did in the past, it's a simple loop after all
<lopex>
unsave!
pglombar_ has joined #jruby
<nirvdrum>
Well, I think some of array intrinsics can vectorize.