Performance

After fixing V8Js’ behaviour of not retaining the object identity of passed back V8Object instances (i.e. always re-wrapping them, instead of re-using the already existing object) I tried how V8Js handles fluent setters (those that return $this at the end). Unfortunately they weren’t handled well, that is V8Js always wrapped the same object again and again (in both directions). Functionality-wise that doesn’t make a big difference since the underlying object is the same, hence further setters can still be called....

Recently @virgofx filed an issue on V8Js whether (startup) performance of V8Js could be increased. He wants to do server-side React rendering and noticed that V8 itself needs roughly 50ms to initialize and then further 60ms to process React & ReactServer javascript code. Way too much for server side rendering (on more or less every request). Up to V8 4.4 you simply could compile it with snapshots and V8Js made use of them....

Today as well as last Thursday I uploaded two more V8Js releases to PECL, both fixing issues around v8::FunctionTemplate usage that bit me at work. Those v8::FunctionTemplate objects are used to construct constructor functions (and thus object templates) in V8. The problem with them? They are not object to garbage collection. So if we export a object with a method attached to it from PHP to JS, V8Js at first exports the object (and caches the v8::FunctionTemplate used to construct it; re-using it on subsequent export of the same class)....

Today I noticed, that invocations of V8Function objects have a really poor call performance. A simple example might be: $v8 = new V8Js(); $func = $v8->executeString('(function() { print("Hello\\n"); });'); for($i = 0; $i < 1000; $i ++) { $func(); } … on my laptop this takes 2.466 seconds (with latest V8Js 0.2.1); older versions like V8Js 0.1.5 even take 80 seconds. That felt strange, since V8Js performance generally is pretty good and the slightly changed version...