Please, test your php code with modx->stopOnNotice = true in index.php

Which I added there.

Wow, I didn’t know php is that forgiving on so much of stuff. Non defined variables, out of bound exceptions in arrays to name some...

Anyway, to be able to truly profile modx, I need to get rid of those 10 x 10 ^ 59949 errors haha.
Just kidding, but there are LOTS and LOTS of php notices, which I would have called warnings actually.

I mean, myArray[somePos] returns a _php_notice_ only when somePos is larger then the size of the array????
Or returning a non defined variable, and it in fact works???
Oh well, I’m new to php as you see ;-)

I solved a number of problems, but there are also a number I don’t know how to solve, I’ll attach my versions of the modified files.
Please, have a look at them, I added comments to my changes, please search in each file for either:
- Remon
- FIXME

And remove those when you merge the fixes or code improvements, but some of the FIXME’s are open since I don’t know the solution.

Please, if those open FIXME’s are fixed, send me those so I can continue profiling modx

Best wishes,

Remon

P.S.
Regarding the Subject, I think it’s rather important to test your code with warnings set to on before you release it to the public.
Avoids nasty problems I guess, and well, it’s just so much cleaner without those 10^324 errors ;-)
Hmmm, I forgot to remove apd_set_pprof_trace();
in index.php, please remove it or you’ll get an error hehe

I think what was done from the early days was to disable php warnings since snippets and many parts of the parser could use undefined variabled.

I’m not sure how this will affect the existing snippets

The problems which I encountered on undefined variables were of these form:



This actually works! But I don’t like it, this seems to be better:



I only saw one problem in a snippet which I’m not sure if it can be solved:



But there was no ’Fin_L’ set, so $_GET[] failed with a warning.

In the parser, those warnings are true ’bugs’ so to speak, which can be solved....

I see in my own project the same habbit to surpress "warnings" because a lot of functionalitty isn’t completely coded, etc.
But in the end, the warnings should vanish somehow ;-)

Remon

Thanks for the ongoing assistance and bug locating prowess.

Quote from: R.S. at Nov 09, 2005, 08:31 AM

I only saw one problem in a snippet which I’m not sure if it can be solved:

$myVar = $_GET['Fin_L'];

But there was no ’Fin_L’ set, so $_GET[] failed with a warning.

There are a couple of ways to handle this sort of thing. One would be:

@ Will supress any warnings or errors. Although this may not work with an error handling function defined, not sure.

The other method, which is probably the better method is:

Hmmm,

If we start doing stuff like:



That’s going to certainly kill performs and make things less dynamic. I thought PHP was a dynamic scripting language and we don’t have to declare or check for variables etc.

LOL

What about doing a quick test by looping through 100 or 1000 iterations with it set and not set and time the results, with notices on and with noticess off.

I wonder if the overhead of outputting/supressing warnings is less than the overhead of "proper" coding techniques?

Another thing Remon is that I used ob_start() and ob_end() to trap warnings and fatal errors message when running a plugin. It allows me to trap the html error message and then save to the event log.

Is there another way we could handle this as I think ob_start() is performance bottleneck.

I’m slowly getting a grip on how to profile modx.

A thing which fooled me a bit was the cache. So if any warnings take place, it will be only one time, so, after the page is cached those warnings don’t show up the next time, which gave me the "idea" the phpError() function didn’t add overhead.

Now see this:

documentParser->executeParser();     -> 88.0 %
documentParser->parseDocumentSource  -> 58.0 %
documentParser->invokeEvent          -> 56.0 %
documentParser->parseProperties      -> 53.0 %
documentParser->phpError             -> 53.0 % !!!!!!!!!!!!!

So, about 60% of the time spend in executeParser is spoiled in phpError() :-(
Note though that the total time spend in executeParser is roughly half the time spend in total php processing time.
But still, if a page isn’t cached, it’s clear that the phpError() function gives a lot of overhead, just by doing nothing actually. (Well, if you run with warnings on, you will see that those warnings are from index out of bound problems)

Regarding ob_start() and ob_end(), I can’t measure a performance difference, so if you want to use it to trap snippet/plugin errors, no problem I guess.
But keep an eye on that one...

Well, a single warning doesn’t add really that much of an overhead you know.
One ’wrong’ $_GET[’blah’] has non measurable performance impact really.

I saw however this one, which is weird performance wise:
in index.php



Heh, I put it there myself you know, cause, in document.parser.blah we check for that value:



For a cached page, so the phpError() doesn’t show up, this one single if statement is good for 5 % of the time spent in executeParser() !!!!!

Either this has to be fixed or done differently, in any case, it’s just to cpu consuming for one single if() statement!


Remon

P.S.
Surpressing warnings!!???
Of course not. Make your code clean and working ;-)
(At least when it’s possible of course.)

Ummm... wow! Keep up the awesome work, and thanks!