HHVM poor performance

Stephan Edelman picture Stephan Edelman · Jul 27, 2013 · Viewed 14.5k times · Source

I'm evaluating HipHop-PHP for compatibility and performance on our code base, but I'm getting very poor performance when running it with the built-in web server enabled.

I have the following sample test program that calculates a Fibonacci sequence.

ex3.php:

function fib($n)
{
    if ($n <= 2)
        return 1;
    else
        return fib($n-1) + fib($n-2);
}

$n = 36;
printf("fib(%d) = %d\n", $n, fib($n, 2));

When I run this through HHVM using the command-line, I get impressive results:

time hhvm -v"Eval.Jit=true" -f ./ex3.php
fib(36) = 14930352

real    0m0.267s
user    0m0.248s
sys     0m0.020s

Compare this with standard PHP:

root@hiphop:/www# time php -f ./ex3.php
fib(36) = 14930352

real    0m5.606s
user    0m5.600s
sys     0m0.000s    

However, when I want to enable the built-in web server in HHVM, all performance gains are lost:

hhvm -v"Eval.Jit=true" -m server -p 8000 &
time wget -qSO - http://localhost:8000/ex3.php
  HTTP/1.1 200 OK
  Content-Type: text/html; charset=utf-8
  X-Powered-By: HPHP
  Date: Sat, 27 Jul 2013 14:16:09 GMT
  Content-Length: 19
fib(36) = 14930352

real    0m5.279s
user    0m0.000s
sys     0m0.000s

As you can see, I'm getting the response back from HHVM, but it taks more than 5 seconds for it to process this request. What am I missing?

Answer

Owen Yamauchi picture Owen Yamauchi · Jul 28, 2013

HHVM engineer here.

In server mode, HHVM will run the first N requests it sees in interpreter-only mode (i.e. with the JIT off).

The default in an optimized build is N=11, so if you were to run the request 12 times, the 12th one would be much faster.

You can tune this with a config option, like so: -v Eval.JitWarmupRequests=3. If you set it to 0, you'll see the speedup immediately.

There are a couple reasons to do this.

First, it prevents transient warmup effects from affecting JIT-compiled code.

For example, the first few requests may need populate values in APC, which will cause the application code to go down different paths from the steady-state paths. This way, we don't waste space on JIT compilations that will only be used a few times.

Second, it allows HHVM to collect profiling information to improve future compilation.

If we observe that a certain value is an integer 99% of the time, for example, we can compile code that's optimized for the integer case. We currently don't have the facility to JIT-compile code with profiling enabled (the hard part is safely throwing it away once we're done with it), so we do the data collection in interpreter-only mode.