From: Cameron B. <ga...@in...> - 2003-03-04 09:17:38
|
Jeff Dairiki wrote: >>>function pagename_to_filename ($pagename) { >>> return preg_replace('/(?<! % | %.)([A-Z])/x', '^$1', >>> rawurlencode($pagename)); >>>} >>> >>> >>>This should escape "~PageName" to "%7E^Page^Name" >>> >>> >>That's 1 way but the reason i suggested ord() was it will be quite fast, >> >>consider that filename length limit on windows is 128 or 256 (forget) >>its not much of an issue unless pages are 64/128chars long. As for >>readability, it wouldnt be hard to make a little script that opened the >>dir and listed like thi >> > >The current official page name limit in PhpWiki is 100 characters. > >I suspect my encoding is faster than your ord() method since >in mine the inner loops are all done in C code. If you want to >use ord, the inner loop (over each of the characters in the >page name) is in PHP. (Ord() only works on one character at a time.) > >However, again, I suspect either way would be plenty fast enough. > > Your function certainly is faster. 10000 loops with your regex real 0m0.379s 10000 loops with ord real 0m0.629s 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. >>Just retested it now (last time it wouldnt work at all, blank page all >>the time) and I got the same as I'm getting in PgSQL, blank pages after >>loading the virgin wiki. >> >> > >Okay, so the problem you're seeing now (blank pages) probably is >not tied specifically to either backend. > > > > >>As for performance, you cant just write off optimizing it knowing that >>wiki is slow, you need to do what you can with all the little things >>first, if its as simple as profiling each function and seeing whats the >>slowest then so be it. (http://apd.communityconnect.com/ for profiling >>abilities >> > >When I wrote the gzcompress code I did profile it. >Oh my (not very fast) machine, the time to gzcompress a few kbytes >of marked up data was barely measurable (a few milliseconds). >That's truly insignificant compared to the total page save time. > > OK, I'll agree to that, obviously there have been a lot of 'only a few more ms' added into wiki tho over time. >You're right in that more careful profiling of PhpWiki would >be highly productive. And you're right --- if one is to >start worrying about non-trivial optimization the only way >to start is by profiling. > >I was unaware of APD. Thanks for pointing that out > 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. >>>I'm no pgsql expert. Are those begin/commits sufficient to prevent >>>concurrent PhpWikis from getting partially updated data? (When the >>>update happens over several UPDATE operations within a single >>>begin/commit, that is.) >>> >>> >>> >>> >>Yes, no data is updated that the other clients can read it until the >>commit is sent. It will also allow multiple people to hit a table at >>once updating not stop the others from doing their thing before they can >> >>write. >> >> > >That's not correct (at least by default). In this mornings readings, >I learned: By default, you get "'Read Committed' Isolation" which does >indeed guarantee that you see no uncommitted data. But that's not >equivalent >to a write lock, in that the state of the database can still change in the >middle of your transaction (through no action of yours). > >It's a subtle enough problem that I'd be very leery about changing the >locking code on a "production" PhpWiki without some very careful >inspection >and testing of the WikiDB code. > >Ref: >http://www.postgresql.org/docs/view.php?version=7.3&idoc=1&file=transaction-iso.html > > > 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? >>It will also allow multiple people to hit a table at >>once updating not stop the others from doing their thing before they can >> >>write. >> >> > >Actually, no it's not. > > > >>Enlighten me, I dont have much time but for worthwhile projects and >>various things I'll use daily im willing to spend a bit of time on them. >> >> > >Well, if you really want to get into the guts of the WikiDB, "use the >source, Luke!" > > I'm trying but with how insanely OOP it is its hard sometimes. 1 minute I have PEAR open, the next i have a wiki lib, the next a config file. Whole lot of fun there. >If you wanted to contribute to PhpWiki, a project which is probably pretty >finite in scope, which would be useful would be to get APD running and >give us a report of some profiling statistics... > > Once I get it working I'll organize some profiles of various tasks and see whats so slow (suspecting the regex's for page highlighting) >>I'll look into where its dying more today, I'v been quite busy. >> >> > >That should be your first priority, PhpWiki-wise, I should think. > > 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? Cameron Brunner inetsalestech.com |