4 ms·
> In real world use cases, how often is that kind of overhead a significant portion of total run time, compared with the actual work? I wish more people paid a
by bradleyland 13y ago
> In real world use cases, how often is that kind of overhead a significant portion of total run time, compared with the actual work?
I wish more people paid attention to questions like this. Be it web servers, app servers, whatever; too many people look at microbenchmarks and decide that a move is imperative when they're really only optimizing a tiny fraction of the total run time.
> Of course, your actual work payload may be faster too in go than ruby if you know how to write it well.
I think that this is the big bet you're going to make when you choose goworker over a Ruby implementation.
What makes this intriguing is that in a web app scenario, background workers are often used for tasks that would take too long to run in the HTTP request/response cycle. This means there is a selection bias toward tasks that may be computationally difficult. That's not to say that all tasks handed off to background workers are CPU bound; many (most, maybe?) are I/O bound, but for the class of problems that are CPU bound, this offers a great solution.
- derefr 13y agoBut for the CPU-bound cases, people are usually calling into a library implemented in C either way (this is why Resque uses a forking model instead of green threads, after all.) The only speed-up you'll get is in the glue, because the task itself will probably use the same C library.
- bradleyland 13y agoIf you're already doing the majority of your work (total run time) in C code, then of course you're not going to benefit from a Golang back-end, but I'd challenge the "usually" portion of your claim. C wrapped in Ruby is not the same as pure C or Golang. The tool-selection argument quickly devolves in to the usual arguments between the benefits of languages like Ruby versus lower level languages, but I'm not sure that's the most productive conversation. That's well traveled ground. What I'm saying is that I'm happy to see this (Golang workers available through a Resque API) as an option. I'm not advocating blindly replacing C implementations (or any other implementation), but I wouldn't be surprised to see a Golang back-end outperform Ruby code, even when that Ruby code is calling in to C libraries. The usual rules apply when making that evaluation. You have to see for yourself.
- benmanns 13y agoYes! I think you capture my intent with goworker. I like to think of it as a halfway point between pure C or C extensions and pure Ruby.