havenwood has quit [Remote host closed the connection]
jnh has joined #rubinius
havenwood has joined #rubinius
jnh has quit [Ping timeout: 272 seconds]
postmodern has joined #rubinius
tenderlove has quit [Quit: Leaving...]
max96at is now known as max96at|off
enebo has joined #rubinius
jnh has joined #rubinius
jnh has quit [Ping timeout: 260 seconds]
max96at|off is now known as max96at
jnh has joined #rubinius
<jnh>
morning
amsi has quit [Ping timeout: 272 seconds]
<|jemc|>
good afternoon
geekbri has joined #rubinius
<jnh>
I wonder when rbx will build from master again :/
amsi has joined #rubinius
<brixen>
jnh: have you tried fixing the issue?
<brixen>
it shouldn't be that complicated
<|jemc|>
jnh: it builds for me
<jnh>
I did try and fix it, but there's too many steps involved and I couldn't figure out where to put the offending code
noop has quit [Ping timeout: 255 seconds]
<jnh>
|jemc|: the problem is when you have no system installed llvm (that configure can detect) and it tries to download and install llvm
<brixen>
but that used to work fine
<jnh>
I've spent about 4 hours on it so far.
<brixen>
so whatever the change is, it's recent
<jnh>
yes, it's to do with the changes for llvm 3.5
<brixen>
it's probably the 3.5 changes
<brixen>
ok, so revert that and see if you can work forward
<jnh>
it's calling llvm-config before it's built and bombing out.
<jnh>
but because it needs that for ldflags I can't figure out how to untease it
<brixen>
hmm
<brixen>
well, one thing I was considering after you pointed me to that issue was removing our support for building llvm
<brixen>
we had prebuilts because almost no one was packaging llvm
<jnh>
yeah. that would make sense.
<brixen>
5+ years later, that's very different
<jnh>
it seems like overkill to me.
<brixen>
we should just require people to install llvm
<|jemc|>
no argument here
<brixen>
also, we could only use llvm if it had rtti
<brixen>
which we don't need anymore
<brixen>
I usually have llvm installed from brew these days
josh-k has joined #rubinius
<jnh>
I'm having trouble with brew on yosemite beta 5 :(
<brixen>
freebsd is clang now, I think
<brixen>
I just updated to GM 3 yesterday
<brixen>
dunno what that corresponds to on the public beta
<jnh>
beta 6
<jnh>
sitting in my update queue.
<jnh>
maybe I'll do that.
<brixen>
heh
<jnh>
that'll kill a few hours :)
jnh has quit [Quit: Leaving...]
gugl_ has joined #rubinius
<brixen>
I've had no issues with llvm on yosemite
gugl_ has left #rubinius [#rubinius]
<brixen>
pretty sure it's still the version I had installed on mavericks
<Gibheer>
yes, freebsd is clang, but llvm does come with the system. But it is easily installable through ports or pkg
<brixen>
yep, 3.4.1 still
gugl_ has joined #rubinius
<brixen>
Gibheer: yeah, that's what I mean, it's a lot easier to find llvm in a normal pkg for your OS these days
<brixen>
of course, there are people on eg 10.04 where I'm not sure they even have 3.0 pkg'd
<Gibheer>
yeah, totally
<gugl_>
hi guys. we are trying to switch from mri to rubinius these days but just found out that rubinius is about 2x times slower in the reails development environment. Are you seeing the same performance issues or are we doing something wrong?
<brixen>
gugl_: slower doing what?
<gugl_>
rendering a simple page in rails
<brixen>
how are you measuring that?
<gugl_>
the main question is if rubinius is typically slowing in rails development environments, tests, etc, compared to mri?
elia has joined #rubinius
<brixen>
it's not really a useful question
<brixen>
some things to consider
<brixen>
rbx use a type-feedback, profiling jit
<gugl_>
well, i did a view comparisons with wrk, but generally it takes about 2 seconds to render a simple rails view
jnh has joined #rubinius
<brixen>
that means that the program needs to run for the JIT to know what to do
<brixen>
it also means the JIT doesn't do anything for your tests
<brixen>
which only run once
<brixen>
the JIT can sometimes make the tests take longer
<brixen>
because it's trying to compile things that won't be used
<brixen>
it also means that the JIT can't do much when you're reloading code in development mode
<brixen>
since that probably causes methods to de-opt
<gugl_>
thats what i thought
<jnh>
all done
<brixen>
so that's why I say it's not really a useful question
geekbri has quit []
<gugl_>
i guessed that the real strengh is the production mode for rubinius. where it can make use of the jit
<brixen>
it's also the case that rbx boots a rails app slower than MRI 2.1 right now
<brixen>
most of the reason for that is rubygems
<brixen>
and I need to fix it
<gugl_>
so, are you just not usually using rubinius for your development environment? or whats the best practice with rails development?
<Gibheer>
I use it for development, but not with rails
<jnh>
damn. still can't build freetype or gdk-pixbuf :/
<gugl_>
ok, then it’s really typical that it’s about 2 times slowing in rails development compared to mri? just asking this kind of silly question as we where looking for things we did wrong as we didn’t want to believe that this is typical.
<gugl_>
so i guess it’s best practice to do development in mri, run the tests on ci with rubinius and then run it in production with rubinius? even though it’s a big mismatch then between prod and dev?
<Gibheer>
it really depends on the work you do. In our system rubinius is a bit faster than MRI when the deamon was running for some minutes and the JIT could do its work. But our application isn't such a huge pile of magic, but just a thin layer to translate database data to user visible stuff and back
<gugl_>
makes sense. as you said, i guess the real issue with rubinius and it’s JIT is the auto-reload in rails. :/
flavio has joined #rubinius
flavio has joined #rubinius
max96at is now known as max96at|off
<gugl_>
brixen: what do you mean by: rubinius is slow booting rails because of rubygems? Are you talking about this issue? https://github.com/rubinius/rubinius/issues/2730 any progress on that?
<brixen>
probably related, yes
tenderlove has joined #rubinius
<yxhuvud>
I wonder what guarantees rubygems/require tries to provide in regards to things changing during runtime . Would it be feasible to cache the directory contents so that it will only be necessary to hit the filesystem if it isn't found?
<yorickpeterse>
gugl_: I've found that the rbx bootup isn't really an issue during development
<gugl_>
Any ideas when it becomes priority in the rubinius team? it’s open for one year now and I guess it’s holding back a lot of people to switch to rubinius
<yorickpeterse>
you only boot up your Rails app once every now and then, and your tests can be made fast enough so you don't really notice it
<yorickpeterse>
also the bootup will be a priority once all the other more crucial problems (e.g. unstable JIT) have been resolved :)
<yorickpeterse>
My little secret will be that once I get my bloody stuff going I'd probably spend far more time on Rbx
<yorickpeterse>
(basically because I have to for my own apps :P)
<yorickpeterse>
which would probably involve taking a peek at the bootup time
<yorickpeterse>
so the tl;dr I guess is "when time permits"
<gugl_>
yorickpeterse: I know, rails boot time is not the big issue for us. It’s the fact that it’s 2 times slower than mri for the easiest requests during rails development and that tests also take a lot more time.
<yorickpeterse>
How did you profile the response time?
<yorickpeterse>
Also worth mentioning: while mean processing times might be lower due to any number of reasons, you can make up for that with parallelism
<yorickpeterse>
(true parallelism that is)
<yorickpeterse>
There are a bunch of components involved in the Rails stack that do make Rbx slower at rendering raw pages compared to MRI 2.1
<yorickpeterse>
e.g. Racc, the routes parser of Rails, is slow, though I'm not sure if that's actually used during runtime or just bootup
<gugl_>
yorickpeterse: I am waiting for 3 seconds to let rubinius render a simple view.
<yorickpeterse>
gugl_: that's far too high, suggesting something might be borken
<gugl_>
how can I enable profiling for the rails server in rubinius?
<gugl_>
that was my question…… are we missing something or is it default for rubinius to take so long……..
<yorickpeterse>
Hm not sure, our built-in profiler basically collects results until it's stopped (either using Ruby code or at the end of a process' lifetime)
<gugl_>
how can i profile my rails server with rubinius? then i will have a starting point maybe.
<yorickpeterse>
So you'd also get stats inc bootup/shutdown code
<yorickpeterse>
You can however use something like siege
<yorickpeterse>
to just bombard it with requests
<yxhuvud>
gugl: is it only in development it is slow? How fast is it in production? (compared to mri)
<yorickpeterse>
Make sure that when you do you're either using Unicorn or Puma, and not crap like webrick
<yorickpeterse>
brixen: unrelated, do we have any metrics on Rbx 1.8 perf vs REE?
<gugl_>
i didn’t do any benchmarks in production yet. but it ‘feels’ really snappy in prod. i know thats not accurate but thats why I guess that the only problem is in dev mode
<gugl_>
we are using puma in prod and dev
<yorickpeterse>
3 seconds is _really_ long though
<gugl_>
oh yes! :)
<yorickpeterse>
Hm I think there was something like rack-profiler, lemme see
<yorickpeterse>
you can just rip out the RbxRackProfiler class and smack it into your Rails app as a middleware
<gugl_>
RBXOPT=-Xprofile bundle exec rails s is running since 3 min on 100% cpu without any logs or progress. strange
<yorickpeterse>
No that makes sense
<yorickpeterse>
The profiler profiles _all_ ruby code, it really slows things down
<yorickpeterse>
so it's better to take a look at that middleware
<yorickpeterse>
it will slow things down, but the ratio should be more or less the same
<yorickpeterse>
(ideally)
<gugl_>
wow thanks for the gist. will give it a try. thanks a lot
<yorickpeterse>
np
<yorickpeterse>
gugl_: so for us right now the biggest help is people trying things out and sharing their findings. Can't guarantee we can fix everything, but at least we can keep track of things
<yorickpeterse>
and eventually we might fix everything (_everything_ :P)
<gugl_>
:) everything that gives a bit of insight is those issues is good. curious by nature :)
elia has quit [Quit: (IRC Client: textualapp.com)]
<jnh>
codeship's testing vm's dont have llvm installed :/
<yorickpeterse>
jnh: rbx should be able to install LLVM it...oh fuck I actually broke that :D
<yorickpeterse>
at least in Rbx master that is
<jnh>
yeah, I need to get master installed to be able to run the Huia tests.
johnmuhl has quit [Quit: Connection closed for inactivity]
leocassarani has quit [Ping timeout: 260 seconds]
josh-k_ has joined #rubinius
leocassarani has joined #rubinius
josh-k has quit [Ping timeout: 272 seconds]
<gugl_>
here is the profile report on the request i was talking about. it’s running the latest (not master) rubinius, rails with puma on vagrant (with nfs folder sharing) https://gist.github.com/gugl/c1fc369a91c6cd139b49
<yorickpeterse>
Hmpf, seems Rails might be using String#tr quite heavily
<yorickpeterse>
though it only makes up 0.08 seconds it seems
<yorickpeterse>
oh wait, that's per call
<yorickpeterse>
even today I suck at reading profiler reports
<yorickpeterse>
meh, I'll see if I can take a look at this this weekend, beats messing around with the CAPI
<yorickpeterse>
but for now I'm off to bed, toodles
<gugl_>
wow. that would be great. let me know if I can help you with testing or anything. I just added a comment to the github issue so that you can find me.
<gugl_>
same for me.
<gugl_>
just one quick last question:
<gugl_>
what framework are the rubinius users working with most of the time. not rails, i guess?
<gugl_>
yorickpeterse:… and thanks again for your support! really great!
flavio has quit [Quit: WeeChat 0.4.1]
houhoulis has joined #rubinius
enebo has quit [Ping timeout: 272 seconds]
tenderlove has quit [Remote host closed the connection]
tenderlove has joined #rubinius
tenderlove has quit [Ping timeout: 246 seconds]
houhoulis has quit [Remote host closed the connection]