[Xapian-devel] PHP Latest

Daniel Ménard Daniel.Menard at Bdsp.tm.fr
Thu Apr 20 14:48:06 BST 2006


Olly Betts a écrit :

>This page seems to say there are some reserved variable names ($argc,
>$argv, $PHP_SELF, $HTTP_*):
>http://aspn.activestate.com/ASPN/docs/PHP/reserved.html
>  
>
I was wrong : PHP declares many variables, depending on how the 
directive "register_globals" is set up.
However, it seems that the page you link is not very up to date : it 
does not mention many of the variables introduced in php 4.1.
These pages are probably more accurate :
http://www.php.net/manual/en/reserved.php
http://www.php.net/manual/en/reserved.variables.php

>I've not actually tested if it causes a problem to use them as a
>parameter name - if it does, we can easily invent a suitable renaming
>scheme.
>  
>
I made a quick test with the following code :
http://www.bdsp.tm.fr/aed/xapian/reserved.php.txt

It seems, that while these variables are created by PHP, nothing 
prevents one to use their name as the name of a function parameter. It 
can't be considered as "good practice", it is not documented as 
explicitely allowed, and of course it won't be possible from inside the 
function to use the global predefined php var, but it seems to work (I 
tested with php versions 4.3.10, 5.0.4 and 5.1.2 under windows and debian).
Even using "$this" as a parameter name doesn't seem to clash anything !

>Anyway, ignoring that for now, I'm now wrapping optional parameters as
>PHP optional parameters.
>Anyway, this reduces the number of methods which use get_func_args and
>call_user_func_array to 23.
>  
>
You really did a great job, and I think that the actual wrapper is near 
perfect!
In my opinion, the only methods which still use call_user_func_array 
(auto_open, quartz_open, muscat36_open_da, muscat36_open_db, mset.fetch, 
enquire.getmset, delete_document, parse_query) are not aimed to be 
called repeatedly, and the php overhead will probably be negligeactable 
compared to the time taken by the function.
I can't imagine a program calling quartz_open 10000 times !
Perhaps there is still some room for improvment in the constructors. 
Many are still using call_user_func_array and I'm not sure that I 
understand why.

>It's worth noting that document_add_posting is the most performance
>critical method for an indexer, since it's the method you're going
>to call most by a large margin (unless you're not indexing with
>positional information.)
>  
>
... and it is now optimally coded in the wrapper, no arrays, no temp, no 
extra functions, just a direct call to the xapian function. And we have 
the real parameter names and the default values of optional ones !
Once again, this is a fantastic work !

>I'm not convinced that should add any overhead to the native calls
>to the flat functions - the coercion check I added wasn't in the
>code path this would take (I added it as an extra check just before
>reporting a type error).  I wonder where this slowdown came from.
>
>Assuming this slowdown repeatable, is vanilla 0.9.5 the same speed as
>0.9.4 or the patched version?
>  
>
I miss time to do the tests just now, but I will as soon as possible.

If I understood correctly, we wish to compare calling the flat functions 
in the following versions :
- 0.9.4 release version
- 0.9.5 release version
- 0.9.5 release version + xapian_wrap7.cc
(0.9.4+patch won't compile because of the new method introduced)

Am I right ?

>But it seems that PHP only accepts a constant for a default parameter
>value - I can't use new or a variable holding an instance of
>SwigPlaceHolder.
>  
>
If I remember correctly, PHP won't accept any "code" as a default value 
(even 1+1 is not supported), so I'm afraid you're out of luck...

>To some extent at least it probably is, but I think you'd need at
>least some hand-crafted code to capture the different features.  For the
>Pythonic iterators we just have fully hand crafted Python code which we
>get SWIG to insert into its generated file (see python/extra.i).  
>  
>
I will have a look.

Best regards,

-- 

Daniel Ménard

Banque de Données Santé Publique
Avenue du Professeur Léon Bernard
35043 Rennes Cédex

Tél. (+33) 2.99.02.29.42
Fax (+33) 2.99.02.26.28
E-mail Daniel.Menard at Bdsp.tm.fr
http://www.bdsp.tm.fr




More information about the Xapian-devel mailing list