<GitHub134>
jruby/master 5c280fa kares: [refactor] get rid of date/format's Bag internal - use Hash...
drbobbeaty has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
ahorek has joined #jruby
ahorek has quit [Client Quit]
drbobbeaty has joined #jruby
shellac has joined #jruby
jrafanie has joined #jruby
shellac has quit [Quit: Computer has gone to sleep.]
jrafanie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
ahorek has joined #jruby
slyphon has joined #jruby
ahorek has quit [Client Quit]
sgeorge has joined #jruby
shellac has joined #jruby
<enebo>
kares: you know if bad was replaced with a class which just had all those fields defined as named methods it would probably even be faster
<enebo>
kares: also we sync lib/ruby/stdlib with a branch on jruby/ruby so changes should be commited there as well so we don't nuke them on next stdlib sync
<enebo>
s/bad/bag/
<enebo>
kares: my theory is we will inline nicely ruby through ruby
<enebo>
kares: although I notice it seems to want to to_hash so hmm I guess I don't know
<GitHub140>
jruby/master 9892b3c kares: move Date's s3e internal into native (based on MRI's C impl)
jrafanie has joined #jruby
<GitHub77>
[jruby] kares opened issue #5255: Date parsing (still) noticeably slower than MRI https://git.io/fNn7P
<kares>
enebo: hey, the internal Bag got away
<kares>
if you're refering to that
<kares>
hmm jruby/ruby I wonder how much it will matter since these aren't updated by MRI's end
<enebo>
kares: yeah I just mean it might be faster to make Bag use real methods than a hash but then I saw it requires being made a hash anyways so I was less sure
<kares>
enebo: MRI uses a Hash internally - so I aligned that
<enebo>
kares: it only matters that headius will copy that repo over the top of this one so if we have commited date/format or whatever there it will replace on next sync
<kares>
there was some time being wasted on method_missing + args boxing but not that much
<enebo>
kares: oh yeah I saw that message
<kares>
haven't looked further ...
<enebo>
kares: I just meant it might inline better as ruby to ruby
<enebo>
kares: I don't know if it actually will though :)
<kares>
maybe I did that one method since its called at the end of every one and I was able to nuke 3-4 regexp matches
<enebo>
oh which method?
<kares>
just a simple one s3e let me find a commit
<enebo>
oh I see that above
<kares>
yep
<enebo>
I was only commenting on the bad replacement
<enebo>
heh bag
<kares>
okay
<kares>
bad bag!
<kares>
:)
<enebo>
yeah I cannot spell bag without a lot of effort
<enebo>
some of these formats would be much better served as actual parsers but that is a lot of work :)
<kares>
well yeah its also a lot of work moving them around
<kares>
haven't done profiling but I expect MRI to be doing the same amount of matching
<enebo>
I was also curious in that benchmark ebcause we have been testing against graal a lot lately
<kares>
at least I have seen most of it in C - they pbly avoid all of the global $1 etc
<enebo>
yeah they probably still use oni for regexps internally?
<kares>
heh I guess these changes might matter less on graal
<enebo>
yeah I am surprised when it works well or not
<kares>
yy internally its pretty much a direct C replacement of what we have in format.rb
<kares>
except they avoid some of the garbage
<kares>
so its either that or those 'big' regexps do not perform that well
<enebo>
an allocation-less parser which sets value into some value object would be the big winner
<enebo>
kares: is there a dominant date parse method which rules in RoR? like iso8601?
<kares>
yy they use all of those I posted in the benchmark code
<kares>
all of them get used iso8601, Date.parse as well as Date._parse
<enebo>
this bench took out the _strptimes but those are already reasonably good I think those are also native
<kares>
parse/_parse for sure on type extracting from DB
<enebo>
ok
<enebo>
pretty common type too
<kares>
yy those are fine
<enebo>
for a db
<kares>
yy + Date._parse gets reused for datetime as well - so its not only date columns
<enebo>
my default options run is very similar to yours but a little bit faster. My laptop is an i7 from about 1.5 years ago
<enebo>
I ran java 8 first too
<kares>
my should be newer
<kares>
but I think I had -Xmx1G
<enebo>
I think indy is not nearly as good in java 9+
<enebo>
second run I am trying compile.invokedynamic just to see
<enebo>
rehearsal is already 5% faster
<kares>
nice
<enebo>
parse 68 -> 61s so improvement but not massive
slyphon has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<enebo>
parse is 44s on graal CE rc1
<enebo>
funny thing I disabled fixnum cache because PEA tends to eliminate the box but it absolutely killed perf for this code
<enebo>
I should also point I had not updated to your changes for those runs
<kares>
44? that might be still worse than MRI
<kares>
altough nice that it shaves 20s away
<enebo>
29s on graal with your changes
<enebo>
44s was before your two commits
<kares>
najs so it made some sense, for now :)
<enebo>
MRI 2.5 is 10s so still 3x best result on graal
<enebo>
I don't know if 2.6 made opts so it may be worse...I guess I should update some shit
<kares>
oh you have 10s ... which one is this _parse?
<kares>
there wasn't much work around date in 2.6
<kares>
I expect it to be the same as 2.5
<enebo>
ok
<enebo>
second to last iso8601 on MRI is about same as graal numbers
<enebo>
although last one is also about 3x that
<kares>
so its likely that they eliminate some regexps along the way
<kares>
do you think like joni is on par with oniguruma?
<enebo>
elimination of regexp would help us a lot since we need to record frame info
<enebo>
kares: I don't know. I remember us being faster in the past for many benches
<kares>
ok
<kares>
I see they have a custom String#sub
<kares>
and avoid "frame" dependance due $1 ...
<kares>
so that might be it
<enebo>
the first 8601 bench does much better than the rest
<kares>
makes sense since it does the least amount of work - only 3 =~ at worst case
<kares>
oh but the DateTime version is pretty much the same
<kares>
so it must be taking the very happy path - no time seen
<kares>
taking a break - will follow up on GH if you find smt interesting :)