On Sun, Dec 19, 2010 at 15:35, Shiplu <shiplu.net@xxxxxxxxx> wrote:
> ===============================================================================
> Recently I my this php-general doesn't accept my mail for some
> reason. So I send it again from anther email
> ===============================================================================
No, actually, you sent it from the exact same address --- but both
came through anyway.
> I am developing a php application that interfaces with an external
> executable binary. The program is written in C++.
> I open the program (say a.out) using proc_open. Write some command at
> its stdin and fetch data stdout. Then close the program.
>
> The timing of only "a.out" is
> real 490ms
> usr 160ms
> sys 290ms
>
> When I invoke it using proc_open in php-cli, the timing becomes
> real 530ms
> usr 50ms
> sys 450ms
>
> Look closely, the cpu time and the real elapsed time increases. I run
> the php version from command line. As an apache handler this will
> surly take more time.
Is this just the processing time of the a.out file, or is this
considering the PHP script's execution time including the a.out
processing? If so, this increase is, of course, to be completely
expected. Also, were the input and output exactly the same size in
bytes as the direct test?
> The program a.out can not be converted in php unless I write an
> extension. But this will need a lot of effort to write it in PHP.
Extensions aren't written in PHP, they're binary packages.
> Some of my ideas are,
> 1. Create a standalone multi-threaded server that calls a.out and php
> calls that server.
This is the same basic idea that Facebook's HipHop project uses.
> 2. Call a.out as a CGI and convert it that way.
This would likely be your best bet, as you're stripping away all
of the excess interfacing by PHP (or another scripting language), and
would instead just be accessing it directly via the web server. That
said, it would depend on whether or not your program is (or could be)
written to handle everything itself, so that PHP - or any capable
language, for that matter - would no longer be necessary.
--
</Daniel P. Brown>
Dedicated Servers, Cloud and Cloud Hybrid Solutions, VPS, Hosting
(866-) 725-4321
http://www.parasane.net/
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
