https://bugzilla.wikimedia.org/show_bug.cgi?id=67168

--- Comment #1 from Bryan Davis <[email protected]> ---
Created attachment 15805
  --> https://bugzilla.wikimedia.org/attachment.cgi?id=15805&action=edit
Test results with HipHop VM 3.2.0-dev (rel)

I have created a test harness on osmium in /home/bd808/projects/hhvm/bug-67168
that can compile hhbc caches and run tests using
maintenance/benchmarks/benchmarkParse.php. A typical test invocation is done as
`/clean.sh && ./build.sh && ./test.sh 2>&1 | tee results/test-$(date
+%Y%m%dT%H%M).log`.

Results for a typical run:

                 | MIN    | MEDIAN | AVG    | MAX
  ---------------+--------+--------+--------+-------
  No RA, No JIT  | 1.0700 | 1.0890 | 1.1139 | 1.5070
  No RA, JIT     | 0.9210 | 0.9860 | 0.9937 | 1.0810
  ---------------+--------+--------+--------+-------
  RA, 1v, No JIT | 1.0960 | 1.1240 | 1.1285 | 1.1470
  RA, 2v, No JIT | 1.1210 | 1.1440 | 1.1601 | 1.3480
  ---------------+--------+--------+--------+-------
  RA, 1v, JIT    | 1.0010 | 1.0240 | 1.0433 | 1.1600
  RA, 2v, JIT    | 0.9790 | 1.0400 | 1.0464 | 1.1070


Preliminary conclusions:

* JIT is faster than no JIT. This seems to be the case even in this contrived
test where the HHVM interpreter is not performing a long running task and
allowed to build up a large optimized bytecode system.

* Using RepoAuthoritative seems to cause a performance penalty when running a
one-off job. This seems likely to be related to the overhead of reading the
sqlite3 database to find the initial bytecode to process. This may have
implications for the execution of jobs and maintenance scripts via hhvm .

* The performance difference between having one and two branches in the HHVM
bytecode cache for RepoAuthoritative execution seems to be nominal at least in
tests which only exercise a single branch. The difference may be related to the
relative size of the sqlite3 databases (55M vs 60M).

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
Wikibugs-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

Reply via email to