<jeremyevans>
headius: Weird, what's the Sequel connection URL you are using?
<jeremyevans>
headius: From that error it looks like the plain jdbc adapter is being used, instead of the jdbc/postgresql adapter, which is strange unless the connection URL doesn't start with jdbc:postgresql
rdubya has quit [Ping timeout: 240 seconds]
<jeremyevans>
headius: from looking at the app, it's DRY/ROM, not direct Roda/Sequel, so you could try asking the DRY/ROM developers. Nothing against DRY/ROM, but I don't have direct experience with it.
<jeremyevans>
headius: if system/boot/persistence.rb:16 is in the backtrace, it's probably something internal in ROM
<jeremyevans>
headius: Might be interesting to benchmark the collect route there since that can theorectically get a lot of traffic
<headius>
yeah sure...I'm seeing JRuby significantly faster than MRI on Rails for the first time I can remember, so I'm eager to check other stuff out
<jeremyevans>
headius: I wouldn't be surprised if JRuby is significantly faster than MRI for roda, it probably depends on how much can be inlined. With roda's block-based approach, MRI proc activation overhead is probably significant
<headius>
with blocks we may be better or worse, depends on how they're structured
<headius>
we should soon be able to get blocks to inline, either at JRuby level or JVM level, and then a lot of that overhead should go away
Puffball has joined #jruby
shellac has joined #jruby
claudiuinberlin has joined #jruby
shellac has quit [Quit: Computer has gone to sleep.]
<kares>
headius: sequel (and others) simply script over JDBC so there pbly will be some (JI) conversion overhead compared to AR-JDBC where there's a native ext
<kares>
still interested in your numbers as it shouldn't be bad - although won't assume we can script Java and beat C drivers :)
olle has quit [Quit: olle]
olle has joined #jruby
shellac_ has joined #jruby
mvintd has joined #jruby
<mvintd>
Having a strange error: I've already required some jar (In this case, JCo) and verified that it's been required by confirming a false return value from a require statement in pry (and I see the jar when checking $CLASSPATH in pry) then I get this error: java.lang.UnsatisfiedLinkError: no sapjco3 in java.library.path
<mvintd>
on jruby 9.1.15.0, mac os x
<lopex>
is there a binary dll in that jar included ?
<lopex>
headius: wrt routes we had a bad regexp case which went utf all the time for quite a while
<lopex>
jeremyevans: so the general case is a list of strings/regexp to check right ?
<jeremyevans>
lopex: are you referring to roda or r10k?
<headius>
mjit slows down more of my benchmarks than it speeds up
<lopex>
jeremyevans: r10k
<lopex>
headius: can mjit throw away any opts and recompile ?
<headius>
nothing like that
<headius>
no inlining either
<jeremyevans>
lopex: it basically sets up 4 different applications per framework, one with 10 routes, 100 routes (10x10), 1000 routes, and 10000 routes
<headius>
I mean they can throw away the code and recompile but it's largely a static translation of yarv IR into C
<jeremyevans>
lopex: the benchmark part just checks each of these routes the same number of times, and compares the results across frameworks
<headius>
jeremyevans: running rails benches now but I have a tab in my spreadsheet for roda stuff
<jeremyevans>
lopex: it's mostly for framework benchmarking in terms of nested route handling
<lopex>
jeremyevans: yeah, is there any smartness to any of those for automatically generalize the rules ?
<jeremyevans>
headius: how do the roda results look for MRI vs JRuby?
<jeremyevans>
lopex: Not sure what you mean there. For the benchmarker, it expects the applications to respond to the routes correctly. How routing is implemented depends on the framework used.
<lopex>
headius: and obviously without correct heuristics mjit will bloat
<lopex>
right ?
<lopex>
jeremyevans: yeah, I mean how the framework optimizes the routes
<lopex>
which is crucial
<lopex>
is the framework sees /a|b/: :foo and 'a': :foo
<lopex>
it should reorder the routes for example
<jeremyevans>
lopex: well, with roda you define the routes via a tree built out of nested ruby blocks
<jeremyevans>
lopex: it's quite a different approach than most other web frameworks
<headius>
jeremyevans: have not gotten that far yet :-)
<lopex>
jeremyevans: same for mine, which is a lot simpler
<headius>
I was stymied in my attempt to use that app I mentioned and returned to microbenchmarks for a bit
<jeremyevans>
headius: OK. Please ping me when you post the final results, I'm definitely interested
<headius>
lopex: well right now it's already pretty bloated...it emits C code on a per-method basis, each compiled and dloaded as a separate library
<headius>
I don't believe they cull or combine so they have to stop jitting at some point because of all the open libs
<headius>
all fixable of course
<headius>
jeremyevans: will do
<lopex>
headius: haw somehow resembling per method classloader :P
<headius>
hah yeah it's similar
<headius>
if we could never collect classloaders
<lopex>
yeah
<lopex>
anyways, sequel rulez
<lopex>
and I say it after using some of the most advanced scala libs :P
<lopex>
quil, you wait for and ide to do anything
<lopex>
slick, too irregular
<lopex>
headius: I will say it again and again AR sucks
<lopex>
jeremyevans: though the as400 lib that was extracted from sequel seems a bit abandoned
<headius>
r10k seems to be running ok with roda + jruby
<jeremyevans>
lopex: that's a shame, but unfortunately I don't have an as400 I can test with (all adapters remaining in Sequel I can test)
<jeremyevans>
headius: great!
<headius>
20k requests at 10k routes, looks like about 4.8s
<headius>
no tuning or anything as far as JRuby is concerned yet
<jeremyevans>
headius: I think MRI is faster, but that may be because r10k does not do any warmup requests
<headius>
that would affect it, yeag
<jeremyevans>
headius: probably fixable without too much work if you'd like me to take a quick look
<lopex>
headius: what is what you want to test exactly ?
rdubya has quit [Ping timeout: 260 seconds]
<headius>
jeremyevans: well if you think it would be easy
<headius>
I'll see what I get with MRI
<headius>
lopex: everything
<headius>
but specifically I want to show some updated numbers for more real-world things
<headius>
along with the micros
<headius>
bleh...rmagick won't build
<headius>
I always have problems with exts when I use MRI
<lopex>
headius: I guess that's the reason so many debian packages exit
<lopex>
debian-ruby-whatever-xxx-package
<lopex>
but no clear solution
<lopex>
jeremyevans: you're on bsd right ?
<lopex>
how do you deal with that ?
<headius>
awesome, rmagick doesn't support imagemagick 7 yet
<headius>
brew install imagemagick@6
<headius>
fun
<headius>
Can't install RMagick 2.16.0. You must have ImageMagick 6.4.9 or later.
<headius>
o_O
<headius>
well I'm not going to get far comparing with MRI if I can't even install
<lopex>
why osx does it to you ?
<jeremyevans>
headius: grab r10k master and use the R10K_ITERATIONS and R10K_WARMUP_ITERATIONS environment variables
<lopex>
headius: for me it smells like gentoo hard conflict
<headius>
jeremyevans: ok
<jeremyevans>
headius: values default to 2 and 0 for backwards compatibility
<headius>
lopex: I have to brew install the right versionand force it to be the main version
<lopex>
headius: does rbenv and the like have and conception of brew ?
<lopex>
seem weird
<headius>
rvm does use brew I believe
<jeremyevans>
lopex: correct, I'm on OpenBSD. We ship a lot of packages for compiled ruby gems. For pure-ruby gems we encourage people to just install them with gem install
<headius>
jeremyevans: does it spin up the server anew for each pass?
<lopex>
jeremyevans: I have hbsd hardcore friends on #scala.pl I'm most on even though I never used it
<lopex>
they have their own package managers
<jeremyevans>
headius: Yes, but it separates startup time from execution time
<jeremyevans>
headius: you'll probably be interested in the runtime.csv file produced instead of the runtime_with_startup.csv file if you want to ignore startup time
<headius>
warmup iters runs at the beginning of each pass then?
<headius>
I guess I can look at the commit
<jeremyevans>
headius: yes. it has to since there is a separate process per pass
<headius>
what was the roda+sql app you mentioned?
<headius>
my buffer went away
<jeremyevans>
headius: cspvr
<headius>
thank you
<jeremyevans>
headius: as I mentioned yesterday, benchmarking the collector route is probably best, since that would be the one getting the most traffic
<headius>
right ok
<headius>
woah yeah iters made a huge difference
<jeremyevans>
it's amazing how many bogus CSP reports are submitted because of MITMs injecting javascript
<headius>
is there a way to have it not clobber the results
<jeremyevans>
headius: Unfortunately not currently, you'll have to copy the data directory somewhere else
<headius>
ok
<jeremyevans>
headius: the reason the default iterations are so low is because sinatra takes like 1000 seconds compared to Roda's 1-2 at 10,000 routes
<headius>
hah ok
<headius>
yeah I did warmup iters 100 and jruby went from 5s for 10k routes down to like 0.5s
<headius>
comparable or faster than MRI
<jeremyevans>
headius: cool
<lopex>
jeremyevans: I know auto-preparization is no longer in sequel now, but are there any plans to gneralize it for jdbc and other vendors ?
shellac_ has joined #jruby
<jeremyevans>
lopex: Not really. If you want to use prepared statements, just use prepared statements. I came to the conclusion that auto-preparing statements is not a good approach for performance.
<lopex>
yeah, I know that
<lopex>
thx
<lopex>
jeremyevans: and that auto was only for jdbc ?
<jeremyevans>
lopex: auto was only for PostgreSQL, and I think it was postgres/pg only and didn't work on jdbc
<jeremyevans>
lopex: but that was about 5-6 years ago, so I could be misremembering
<lopex>
ah
shellac_ has quit [Ping timeout: 248 seconds]
<lopex>
jeremyevans: somehow I thought it was for jdbc since it would have the most effect
<lopex>
and would be the most universal for some point for view