feature request - force JIT on every request to optimize marked blocks of code

[ghost]

simple example file: <?php main(); function main() {

cached JIT code

$a = $_GET['optionA']==='1'; $b = sanitize_blah($_GET['optionB']); define('myConst', $_GET['foo']==='1'); etc etc

blah

FORCE JIT START = $a, $b, myConst

for ($i=0;$i<1000000000;++$i) { if ($a===true) {#unnecessary expressions will get removed from the hot code

blah

} else {

blah

}

more hot loop code

}

FORCE JIT END

more cached code

} ?>

we save the JIT engine time by naming specifically what variables and constants we want to be optimized.

A note about constants Constants are useful in HHVM because they're fast and global so you don't have to pass as many variables around as params for every function. The "global is bad" idea doesn't apply to constants because they can't mutate after they've been set. Recently by changing my string hashes to constants (set to integers) I got a 21% speed gain. eg: $giantArray[$i]['foo']; became $giantArray[$i][foo];

[scannell]

Thanks for reporting this. Feel free to submit a PR if you (or someone else reading this) get to it. We likely won't get to this for a while since it won't provide much benefit for large scale applications beyond RepoAuthoritative + WholeProgram mode and we don't want people to have to micro-optimize like this.

[ghost]

Thanks Scannell. When do you guys plan to have the profiler working and modifying code in realtime? That would be good for big loops, observing them at a low priority and then cutting out the unnecessary operands or expressions, without requiring manual optimization as above.

[scannell]

Performance work on HHVM is ongoing and continues to be one of the main focuses of the team.

[ottoni]

lope, the JIT already has a profiling mechanism. However, the JIT doesn't recognize loops yet, so it can't do loop optimizations (including loop unswitching in your example). We're working to increase the size of the JIT compilation regions, which will allow it to capture loops and then apply loop optimizations. But it'll be a few months until we get there.

[ghost]

Thanks for sharing your awesome work guys. I'm looking forward to contributing some PRs when I can.

[fredemmott]

• Until it's ran a few times, we run a high risk of making a suboptimal version
• Re-JITing it every time will be slower than interpreting it