Open JeroenDeDauw opened 9 years ago
Is all that time really just spend only inside ParamProcessor itself?!
@mwjames can you link to some short into on how to run such profiling?
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.
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/
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.
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
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.
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.
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 simpleask query
like: