[WATCH_D0GS UNITED]

Description

This include currently contains faster alternatives to the following AMX Mod X core functions:

PHP Code:

clamp( value, min = cellmin, max = cellmax );
max( value1, value2 );
min( value1, value2 );
random( max );
toupper( c );
tolower( c );
swapchars( c ); 


The functions provided in this include use less CPU and RAM compared to the default ones,
thanks to simplified logic and reduced memory allocation through macros ( when possible ).

More function-like macros and stocks will be added in the future.


Below are the profiling results for each function.

Functions terminated in '_R' are the faster ones provided by this include.

Each instance of flTime below is the ~'time spent' by the function in a different profiling moment.



swapchars_R( 1738272608 );
flTime: 0.000791
flTime: 0.000813
flTime: 0.000801

swapchars( 1738272608 );
flTime: 0.001807
flTime: 0.001838
flTime: 0.001890

Result: swapchars_R performed 2.28 times faster than swapchars.

toupper_R( 'd' );
flTime: 0.000381
flTime: 0.000377
flTime: 0.000382

toupper( 'd' );
flTime: 0.009422
flTime: 0.009378
flTime: 0.009560

Result: toupper_R performed 24.87 times faster than toupper.

tolower_R( 'D' );
flTime: 0.000377
flTime: 0.000377
flTime: 0.000377

tolower( 'D' );
flTime: 0.009572
flTime: 0.009492
flTime: 0.009444

Result: tolower_R performed 25.05 times faster than tolower.

max_R( 40, 50 );
flTime: 0.000377
flTime: 0.000377
flTime: 0.000377

max( 40, 50 );
flTime: 0.001623
flTime: 0.001672
flTime: 0.001585

Result: max_R performed 4.2 times faster than max.

min_R( 40, 50 );
flTime: 0.000377
flTime: 0.000377
flTime: 0.000377

min( 40, 50 );
flTime: 0.001596
flTime: 0.001567
flTime: 0.001564

Result: min_R performed 4.14 times faster than min.

random_R( 50 );
flTime: 0.000606
flTime: 0.000626
flTime: 0.000608

random( 50 );
flTime: 0.001708
flTime: 0.001689
flTime: 0.001799

Result: random_R performed 2.81 times faster than random.

clamp_R( 40, 50, 60 );
flTime: 0.000395
flTime: 0.000377
flTime: 0.000377

clamp( 40, 50, 60 );
flTime: 0.001761
flTime: 0.001702
flTime: 0.001714

Result: clamp_R performed 4.51 times faster than clamp.

*Profiling results in this page are accurate and were obtained in
appropriate environment at similar conditions using the same notebook.

*Different computers may obtain lower or higher diffs. than the proportions herein displayed.

[fysiks]

It is highly unlikely that any of these will actually make any appreciable difference to a server.

[mlibre]

[Bugsy]

Agree with fysiks, this is overkill on modern day computers. I understand its cool/fun to experiment and see these improvements, but I do not foresee anyone using this include.

[anssik]

Nice work, optimization is always a good thing.
But I think you should just replace the original functions with the optimized ones instead of creating a new include, make it a pull request on the amxmodx github

[fysiks]

Originally Posted by anssik optimization is always a good thing.

I would say it's not always a good thing.

Originally Posted by anssik But I think you should just replace the original functions with the optimized ones instead of creating a new include, make it a pull request on the amxmodx github

Realistically, this will never make it into the official code, one reason being that the project is practically dead, another being my post above.

[bigdaddy424]

great discovery, i wonder how did you came up with these functions and id appreciate if youre willing to show the method used to measure time this accurate

[HamletEagle]

Originally Posted by bigdaddy424 great discovery, i wonder how did you came up with these functions and id appreciate if youre willing to show the method used to measure time this accurate

I'm afraid there is no "discovery" here.

Most of the macros from the include (like clamp, max, min, random) have conceptually identical implementations to what the amxx core is doing. The only difference is that the implementation is directly inside the plugin and doesn't have to pay the penalty of doing a native call to obtain the result.

swapchars might look complex, but again, it's just a common-sense implementation that is directly placed in the plugin and doesn't have to communicate with the core to pass arguments, make a native call, etc. If you have a cellsize of 32 bits for example, that is 4 bytes. In memory, they look like BYTE0 BYTE1 BYTE2 BYTE3. Then it's just a matter of writing the proper bitwise operations using masks and shifts to re-arrange the bytes to BYTE3 BYTE2 BYTE1 BYTE0.

It's not like OP has found a revolutionary way to implement max, it is the same implementation but directly in the plugin.