Re: [PHP-DEV] Windows (Visual Studio) compiler stuff

[email protected] ("Matt Wilmas") Sun, 22 Nov 2015 19:28:00 -0600
Newsgroups php.internals,php.internals.win
Message-ID <B72474C8C84444A8A23C9201510F37C6@pc1>
Hi Anatol, Dmitry, all,

Will reply about the original subject issues soon, but this is about new 
stuff I noticed the other day...  Adding Matt Tait and Nikita because of PR 
#1418 and comments.

Anyway, the new Control Flow Guard (/guard:cf) is causing a big slowdown on 
bench.php. :-(  14% on a Yorkfield (Q9400) and 19% on a Sandy Bridge 
(Celeron G530).  Ouch.  Did anyone else check the performance impact?  Is 
this acceptable?  On any other platform...?

I'll definitely remove that from my builds (Elephpant Sanctuary, coming 
soon) since it's useless on all but the latest Windows versions anyway.

But if that "feature" must remain enabled otherwise, I think we can 
eliminate most of the performance hit.  As Nikita wondered about, I first 
wanted to look at the indirect calls to the opcode handlers.  I tried 
separating out zend_execute.c in the Makefile and added /guard:cf-   Bingo! 
That restored about 98% of the speed on bench.php.  It reduced 
the --disable-all NTS DLL by 13.5 KB (of the 67 KB added by full CFG).

Or could maybe change back to the old SWITCH executor?  I didn't try that.


It seems like it would be a good "rule" to not use any MS stuff that isn't 
done on other compilers/platforms. :-)

/GS [1] is another that is/was starting to get annoying (function 
prolog/epilog); luckily I was able to suppress it in most cases with changes 
I'm making.  It's enabled by default, of course, although I see it's 
commented out in a line (old?) of confutils.js.  /GS-   ;-)   I really hope 
there aren't places where we are not doing range checks, etc. ourselves 
(that the compiler can't see).  So, either /GS is a waste, or it's only a 
matter of time with other compilers?!

[1] 
http://stackoverflow.com/questions/6607410/understanding-buffer-security-check-gs-compiler-option-in-msvc


- Matt