[AndreT]

Quote:

Originally Posted by Mellnik Why does the speed matter? You should choose the plugin which provides the best features. I just made a speed test for you anyway, RoW001. Code: #1 BlueG/maddinat0r: 4519 ms (R37) #2 Dan..: 7173 ms (2.6) #3 Andre's SFSE plugin?: 26158 ms (v1?) https://mega.co.nz/#!ltQgHZwL!DonDSd...oV_uJUzKrkZ_v0 Sorry if I made a mistake in it, did it very quick out of fun.

Hey. Interesting results, but they seem to be for an older version of my plugin (newer one does not have a connect native, but loads the data from a file - sort of a bad decision, but I did not go to recreating the function because my code connected internally).

Nevertheless, I assume these results are correct since you do call 1000 queries. Benchmarked versions of the other 2 plugins already support processing multiple queries at once. What mine does is block new queries from being ran and processed before the server ticks (ProcessTick) and the returning callback is called. The others AFAIK don't do that and allow more than one query to be pipelined for PAWN returning callback execution, so one ProcessTick can handle calling OnTableFetch more than once.

I have, about a year ago I reckon, benchmarked my plugin against the other two by handling a result set of 300k rows. I was able to speed mine up very decently by, for example, calling .reserve(300000) on the vector before passing the rows to it (and it makes perfect sense, this saves a ton of reallocations) and compiling with -O3 (on a newer gcc, might go for -Ofast). Also mine does not incorporate a ton of security checks because my plugin was mostly for personal use, so I knew what I was doing with 4-5 years of experience already. Also had simpler handling of NULL values and AMX callback parameters. All this led to my plugin being 3-4 times faster at processing these rows.

Go for the plugin which offers the best set of features unless the processing times don't differ a tenfold!