Re: [Phpwiki-talk] pgsql bug

[Jeff D. <da...@da...>]

On Tue, 04 Mar 2003 19:18:03 +1000
Cameron Brunner <ga...@in...> wrote:


> >I suspect my encoding is faster than your ord() method since
> >in mine the inner loops are all done in C code.


> Your function certainly is faster.

Woohoo! I win, I win!
(What do I get?)


> The reason I was suggesting ord() is that I avoid regex's because nearly
> 
> every time I use them they are slower than doing it the simplest way in
> PHP.

As long as the "simplest way" is a built-in PHP function, then yes.
But if the regexp allows you to avoid inner loops in PHP, then it's
probably a good thing.



> OK, I'll agree to that, obviously there have been a lot of 'only a few 
> more ms' added into wiki tho over time.
 
Yes. The motivation (particularly in 1.3.x) has been for features
rather than for speed.

If you want something light-weight, than PhpWiki is probably not for
you.

(I'm not saying that profiling/optimization wouldn't be helpful, but
we've got enough lines of code, that we're never going to be blazingly
fast.)


> Profiling is god when it comes to cleaning up your code. So many 
> applications I have managed to triple or better their speed with careful
> 
> use of APD. APD has since moved to pear (only found this out when i went
> 
> to reinstall it). I can't get it to compile AND work tho so I dont know 
> whats up with that. http://pear.php.net/package-info.php?pacid=118 has 
> the latest versions.

Oof.  I'll take a quick look into it and see if I can get it to work.
 
> I really could have done WITHOUT knowing that, now to rewrite a lot of 
> code. Thanks for the info tho. Well the way I set it then its a case of 
> setting to serialize and then falling back to begin/commit?

Yes, that's the safe, paranoid approach.
BUT note that if you use "serialize", then your UPDATEs and DELETEs will
fail with "ERROR:  Can't serialize access due to concurrent update"
upon concurrent updates.  (That doesn't happen if you don't use
"serialize" transaction mode.)   So you'll have to check for and handle
that.
(I believe at that point, you have to ROLLBACK and start the whole
transaction again...)

(I'm now remembering why we just lock the tables...)

If you're really interested in performance, then you need to take a
closer look at your code and figure out exactly which level of concurrency
protection you do need.

> I could scream now, turns out it REFUSES to output anything when using 
> suexec cgi-bin php, module php works tho, does anyone know the reason 
> for this? Is this done on purpose or what?

Oh.

Take a look at the giant funky nested IF tangle at the bottom of
index.php.  It's supposed to call main() when index.php is invoked
as the top level PHP script, but not when index.php is included
by some other script.  (Someone added that to support image caching
by plugins --- and it does need to be fixed.)

Make sure 'lib/main.php' is actually being included.
(If you're not using the image caching you can just get rid of
all the ifs.)


Then again, if you're getting SQL action out the back (like you said 
you were) I think that means it must be getting past index.php....