You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jan 13, 2022. It is now read-only.
I'm using the convenient oss-performance driver script to run real frameworks.
I want to be able to run the HHVM under test (UUT) compiled with GOOGLE_CPU_PROFILER. I currently set the env variable CPUPROFILE to name the file to dump profile info to when the UUT exit's cleanly, but if I happen to run the oss-performance driver script itself with a HHVM that was also compiled for google performance, then the CPUPROFILE env var will control both invocations of HHVM, and chaos ensues in regards to which HHVM really wrote the file named by CPUPROFILE.
Perhaps the oss-performance driver script could, under yet another flag, probe for the admin server requests /prof-cpu-on and /prof-cpu-off and if present, then have the admin server on the UUT turn on/off the profiler itself, and then the obnoxious CPUPROFILE env var wouldn't be needed.
Yeah, creeping featurism
The text was updated successfully, but these errors were encountered:
I'm using the convenient oss-performance driver script to run real frameworks.
I want to be able to run the HHVM under test (UUT) compiled with GOOGLE_CPU_PROFILER. I currently set the env variable CPUPROFILE to name the file to dump profile info to when the UUT exit's cleanly, but if I happen to run the oss-performance driver script itself with a HHVM that was also compiled for google performance, then the CPUPROFILE env var will control both invocations of HHVM, and chaos ensues in regards to which HHVM really wrote the file named by CPUPROFILE.
Perhaps the oss-performance driver script could, under yet another flag, probe for the admin server requests /prof-cpu-on and /prof-cpu-off and if present, then have the admin server on the UUT turn on/off the profiler itself, and then the obnoxious CPUPROFILE env var wouldn't be needed.
Yeah, creeping featurism
The text was updated successfully, but these errors were encountered: