Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Speed #10

Closed
3F opened this issue Jan 23, 2017 · 0 comments
Closed

Speed #10

3F opened this issue Jan 23, 2017 · 0 comments
Labels
Milestone

Comments

@3F
Copy link
Owner

3F commented Jan 23, 2017

For planned v1.3 I implemented new caching of the binding in core provider

test via snet tool (part of regXwild)

x32 library:

Unicode: true
iterations(10000) x average(4)

.... regXwild via Conari (Lambda) - ESS version: ~61ms
.... regXwild via Conari (DLR)- ESS version: ~222ms
.... regXwild via Conari (Lambda) - EXT version: ~58ms
.... regXwild via Conari (DLR) - EXT version: ~218ms

....

x64 library:

.NET version via Conari engine

Unicode: true
iterations(10000) x average(4)

.... regXwild via Conari (Lambda) - ESS version: ~43ms
.... regXwild via Conari (DLR)- ESS version: ~245ms
.... regXwild via Conari (Lambda) - EXT version: ~37ms
.... regXwild via Conari (DLR) - EXT version: ~237ms

#####

The regex engine is much more slower (~30-90sec for 10000 iterations), please wait...


Compiled: true
iterations(10000) x average(4)

.... .NET Regex engine: ~37611ms
.... .NET Regex engine(only as ^match$ like a simple '=='): ~2ms

-------

Compiled: false
iterations(10000) x average(4)

.... .NET Regex engine: ~31034ms
.... .NET Regex engine(only as ^match$ like a simple '=='): < 1ms

Done.

looks good !

old result:

( <= v1.2) +icase [x32] +icase [x64]
regXwild via Conari (Lambda) - ESS ~1032ms ~1418ms
regXwild via Conari (DLR) - ESS ~1238ms ~1609ms
regXwild via Conari (Lambda) - EXT ~1117ms ~1457ms
regXwild via Conari (DLR) - EXT ~1246ms ~1601ms

but I'm not sure about that binding to specific values are correct for all cases. I added new unit-tests and this also looks good, so ...

Currently I implemented this via 0x29 opcode (Calli), and the all arguments should be pushed onto the stack before each calling.
Thus the cached TDyn should be valid for custom values via std. stack

for(int i = 0; i < mParams.Length; ++i) {
    il.Emit(OpCodes.Ldarg, i);
}

Use IProvider.Cache if not, and report about this here.

@3F 3F added the support label Jan 23, 2017
@3F 3F added this to the v1.3 milestone Jan 23, 2017
@3F 3F closed this as completed Nov 10, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant