
6 Line EventMachine Bugfix = 2x faster GC, 13x requests/sec - EvilTrout
http://timetobleed.com/6-line-eventmachine-bugfix-2x-faster-gc-1300-requestssec/
======
rcoder
And this, kids and kid-ettes, is why having someone who knows their way around
your C compiler, assembler, and debugger on your team can be worthwhile, even
if you're working in a high-level language like Ruby.

~~~
judofyr
Even if you're working in a high-level language like a C extension to Ruby?

~~~
jey
They had to patch the C extension to make their Ruby code go faster. They
weren't hacking the C extension to begin with.

~~~
scott_s
It certainly looks like a C++ module is part of their project:
<http://github.com/eventmachine/eventmachine/tree/master>

------
cperciva
This is why I hate garbage collection -- it tends to break horribly as soon as
someone does anything unexpected. Using 800 kB of stack is an incredibly dumb
thing to do (not as bad on a 64-bit system as it is on a 32-bit system,
admittedly), but it still shouldn't cause a huge drop in performance.

~~~
briansmith
"It tends to break horribly as soon as someone does anything unexpected" is
usually the argument used against _manual_ memory management.

~~~
cperciva
No. Using malloc/free will break if your code is broken -- but you look at
your code and prove that you're not using memory after it has been freed, not
accessing memory locations outside of the allocated regions, and not
allocating unbounded amounts of memory, then you have a guarantee that memory
management won't cause new problems for you.

With garbage collection it's possible to have perfectly correct code which
nonetheless breaks horribly as a result of the garbage collector being "smart"
in very stupid ways.

~~~
briansmith
You make that proof sound easy. In reality, proving that code is correct is
one of the most difficult things that a programmer can be tasked with. And,
even if you _could_ program is correct, somebody could make a small change--
even a single character--and invalidate your whole proof. That is the primary
reason garbage collection exists.

~~~
psranga
If we interpret what cperciva said to mean 100% correct proofs you're correct.
But you can do a _lot_ of things in C++ to avoid memory leaks/reading from
freed memory etc.

Some of them are:

1) are auto-freeing templatized heap object class (the compiler will
automatically call destructor when objects goes out of scope, call free in the
destructor).

2) Overload free/delete to fill up freed memory with 0xdeadbeef etc so that
code that reads from there is likely to crash due to invalid data.

3) Use one of the non-libc memory managers which will track memory allocs and
frees and tell at exit if all memory was freed. Some will even have tricks to
tell you _which_ allocation was not freed.

4) If all else fails, use Valgrind for the really tough ones.

Coupled with a good regression/unit test suite, memory leak tracking will be
an insignificant part of your development effort.

~~~
briansmith
I am building a set of cross-platform mobile applications. In order to get the
application working on as many devices as possible, I am writing the same
programs multiple times: in C++ (Windows Mobile & Symbian flavor), in Java
(ME, Android, and Blackberry flavors), in Objective-C (iPhone flavor), and in
one case even Flash. These are all different implementations of the exact same
program written by the same programmer who has more than 10 years of exposure
to Java and C++.

Without a doubt, the #1 biggest waste of time in coding the application is the
manual memory management required in C++. Symbian C++ is particularly
horrible, but the memory management still sucks even when I get to write
"standard" C++. And, it sucks right from the beginning (which kind of smart
pointer do I need here?) through the middle (does this API call take over
ownership of this pointer or not?) all the way through the end (am I _sure_ I
got it all correct before I pay for this $200 signature?). I can take some
shortcuts in the C++ versions because they have more memory to work with than
the Java versions, but still the memory management is a much bigger hassle in
the C++ versions than in the Java versions.

~~~
joeyo
At the risk of hijacking the thread, since you are coding the same apps on
multiple handheld platforms/languages, would you care to comment on which
platform you enjoy developing in the most and why?

~~~
briansmith
If it is possible to do it in Java ME, then Java ME is the best. It is so easy
to code for, it is the most widely deployed by far, and it is easy to port to
Android and Blackberry. Unfortunately, there are a lot of cases where the user
experience with Java ME is sub-optimal to native apps or some capability is
exposed only via the native API.

Windows Mobile is probably the worst because it has a pretty low market share,
it is expensive to get started, and it is pretty tedious to code for.

Symbian is the most tedious to code for but it has a huge market share.

The iPhone SDK is the only way to make iPhone apps, and the iPhone is
obviously very important so you can't ignore it. It was the most expensive to
get started for because it more-or-less requires the purchase of a Mac.

Android is easy to code for right now but I've heard that the Cupcake update
is causing a lot of people pain. When more devices from more manufacturers are
released on more carriers, we may find that Android is not much better than
Java ME in terms of ease-of-coding.

------
abstractbill
The real question is, why does Ruby still use a mark-and-sweep GC?

~~~
wingo
That is not the issue at hand. The issue is conservative scanning of the
stack.

------
gojomo
The local fix is nice, but I would be tempted to offer a solution for all code
that does the same thing -- put a big chunk of GC-opaque data on the stack. It
might take the form of informing the garbage collector: skip this range.

------
jacktang
Well, one of my friends drop me one formula. Let x to be the rate of GC time
out of total running time, and we can get

(1-2x) * 14 = 1- x => x = 13/27

which means now ruby spends 13/27 time on GC, fast enough? (before patch, it
spends 26/27 time on GC, really bad)

~~~
dfranke
I don't see how you're getting this formula, but if it spends 13/27 on GC
after a 2x GC speedup, then it was 26/40 before, not 26/27.

------
dinkumthinkum
This was a very interesting discussion.

