e but make this
work. For example by passing a callback via tsrm_startup(}.
Andi
> -Original Message-
> From: Derick Rethans [mailto:[EMAIL PROTECTED]
> Sent: Monday, May 28, 2007 8:14 AM
> To: Stas Malyshev
> Cc: Rasmus Lerdorf; Uwe Schindler; 'PHP Internals'
On Fri, 25 May 2007, Stanislav Malyshev wrote:
> It's great to have a benchmark, thanks!
>
> > The standard of deviation was rather high though. Over 10 runs on each
> > the averages were:
> >
> > time: 646 req/sec
> > sapi: 659 req/sec
>
> So it's 2%, not that big a deal...
I think it is...
But that doesn't fix the broken side-effects we already have in the
locking code depending on defines in the individuals SAPIs which Uwe
showed isn't working either. And if we exclude locking from TSRM as
Well, that's different problem which I can't really tell about because I
don't know enoug
Stanislav Malyshev wrote:
>> Well, by that logic you would be fine with:
>>
>> #define TIME_CALL sapi_get_request_time(TSRMLS_C)
>>
>> and in tsrm_virtual_cwd.c
>>
>> #ifndef TIME_CALL
>> define TIME_CALL time(0)
>> #endif
>> ...
>> t = CWDG(realpath_cache_ttl)?TIME_CALL:0;
>
> Theoretically yes,
It's great to have a benchmark, thanks!
The standard of deviation was rather high though. Over 10 runs on each
the averages were:
time: 646 req/sec
sapi: 659 req/sec
So it's 2%, not that big a deal...
--
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED] http://www.zend.com/
--
P
Well, by that logic you would be fine with:
#define TIME_CALL sapi_get_request_time(TSRMLS_C)
and in tsrm_virtual_cwd.c
#ifndef TIME_CALL
define TIME_CALL time(0)
#endif
...
t = CWDG(realpath_cache_ttl)?TIME_CALL:0;
Theoretically yes, that could work, but:
that makes it environment-depende
I did a bit of rather unscientific benchmarking using my old
bench_main.php script which tries to be a bit more than a
microbenchmark. The fastest run for each were:
time(0):
1 fetches, 5 max parallel, 2.73e+07 bytes, in 15.314 seconds
2730 mean bytes/connection
652.998 fetches/sec, 1.78268e+
Uwe Schindler wrote:
> Hi Rasmus,
>
>>> This is no longer the case. E.g. when compiling the module for the NSAPI
>>> webserver (Sun Java System Webserver) there should be a global define
>> like
>>> -DNSAPI in the makefiles (not only for nsapi.c) which is not. Because of
>>> that all SAPIs do not
Hi Rasmus,
> > This is no longer the case. E.g. when compiling the module for the NSAPI
> > webserver (Sun Java System Webserver) there should be a global define
> like
> > -DNSAPI in the makefiles (not only for nsapi.c) which is not. Because of
> > that all SAPIs do not have an effect on the thre
Uwe Schindler wrote:
>>> It would be perhaps OK to make TSRM dependent on some global PHP
>> functions,
>>> but to make it depend on SAPI code that is only for webserver
>> interaction
>>> (!) and not related to TSRM (yes SAPI uses TSRM but not the other way
>> round)
>>> is not so good. And that o
Stanislav Malyshev wrote:
>> quite expensive. And SAPI isn't only for web server interaction. SAPI
>> is a general-purpose abstraction API that sits between PHP and anything
>> PHP talks to. CGI, CLI, and even embedded PHP are all SAPI-driven.
>> There is no way to use PHP without at least a stu
> > It would be perhaps OK to make TSRM dependent on some global PHP
> functions,
> > but to make it depend on SAPI code that is only for webserver
> interaction
> > (!) and not related to TSRM (yes SAPI uses TSRM but not the other way
> round)
> > is not so good. And that only because of a not IO-
quite expensive. And SAPI isn't only for web server interaction. SAPI
is a general-purpose abstraction API that sits between PHP and anything
PHP talks to. CGI, CLI, and even embedded PHP are all SAPI-driven.
There is no way to use PHP without at least a stub SAPI layer.
There is, however, a
Uwe Schindler wrote:
>>> An extra syscall on every file open isn't exactly miniscule.
>> It's a syscall not related to any filesystem or I/O so it can't be that
>> bad. And we managed to live with it so far.
>>
>>> Edin also just built Windows binaries without problems. Why did it work
>>> for him
> > An extra syscall on every file open isn't exactly miniscule.
>
> It's a syscall not related to any filesystem or I/O so it can't be that
> bad. And we managed to live with it so far.
>
> > Edin also just built Windows binaries without problems. Why did it work
> > for him?
>
> I have no ide
Stanislav Malyshev wrote:
> I tried removing recently added include to SAPI.h and it compiles just
> fine now. In general, I think linking TSRM to SAPI is not a good idea.
> It means, among other things, that TSRM can never be used in a context
> that not links it to PHP. This is something that was
An extra syscall on every file open isn't exactly miniscule.
It's a syscall not related to any filesystem or I/O so it can't be that
bad. And we managed to live with it so far.
Edin also just built Windows binaries without problems. Why did it work
for him?
I have no idea. But it is obvio
I tried removing recently added include to SAPI.h and it compiles just
fine now. In general, I think linking TSRM to SAPI is not a good idea.
It means, among other things, that TSRM can never be used in a context
that not links it to PHP. This is something that wasn't before and I
don't think t
Recent TSRM changes seem to break the windows compilation for me. I'm
getting:
tsrm_virtual_cwd.c
C:\Program Files\Microsoft Visual Studio
8\VC\PlatformSDK\include\winsock2.h(112
) : error C2011: 'fd_set' : 'struct' type redefinition
C:\Program Files\Microsoft Visual Studio
8\VC\Platf
19 matches
Mail list logo
