search

JeroenDeDauw / ParamProcessor

Declarative parameter processing library
https://entropywins.wtf
Other
20 stars 4 forks source link

XDebug profiling / ParamProcessor performance #3

Open JeroenDeDauw opened 9 years ago

JeroenDeDauw commented 9 years ago

Reported by @mwjames in https://github.com/JeroenDeDauw/Validator/issues/5

XDebug profiling on SMW's query processor shows some rather unusual performance degradation for the ParamProcessor on a simple ask query like:

{{#ask: [[Modification date::+]]
|?Modification date
}}

queryprocessor-paramprocessor-1

queryprocessor-paramprocessor-2

queryprocessor-paramprocessor-3

JeroenDeDauw commented 9 years ago

Is all that time really just spend only inside ParamProcessor itself?!

JeroenDeDauw commented 9 years ago

@mwjames can you link to some short into on how to run such profiling?

mwjames commented 9 years ago

Is all that time really just spend only inside ParamProcessor itself?!

Yes, the 359 ms belong solely to the doParamProcessing method with all its succeeding calls.

mwjames commented 9 years ago

can you link to some short into on how to run such profiling?

Under the assumption that Xdebug is installed, I normally switch on [0] for the targeted webpage (in above case that includes the ask query) to generate the Xdebug profile (which is stored as Xdebug cache grind file, see also [1, 2]).

Above screenshots are made by using WinCacheGrind on Windows.

[0] https://chrome.google.com/webstore/detail/xdebug-helper/eadndfjplgieldjbigjakmdgkmoaaaoc?hl=en [1] http://xdebug.org/docs/profiler [2] http://naveensnayak.wordpress.com/2013/06/26/setting-up-kcachegrind-in-ubuntu/

JeroenDeDauw commented 9 years ago

Yes, the 359 ms belong solely to the doParamProcessing method with all its succeeding calls.

I have test suites from which 500 tests run faster than that. So wtf... how can this one getParamsToProcess method take 7ms or more? Maybe it's this sorting thing, being invoked the whole time for no good reason. Anyway, this whole thing should run under 10 ms, else it's just bad.

JeroenDeDauw commented 9 years ago

I'm going to kick this code into a somewhat better shape, and see if I spot any silly stuff going on while doing so

JeroenDeDauw commented 9 years ago

Actually looking at how much tangle there is for the relatively little amount of functionality, I'm think it's probably more efficient to rewrite from scratch. First going to do another check for similar libraries.

JeroenDeDauw commented 8 years ago

So I had a go at this in the week or so after writing that last comment and found out that this is actually not all that little functionality, and that it is not a small task to build it from scratch.