Add Lazy<Regex> for performance gain in Hex variables

[MarcosMeli]

Hi there, great work with the library, here is some small optimization of the code

To avoid the creation of the Regex in the first use of the class is
better to instanciate the Regex in the first use of the EncodeHex method
(if never called so no Regex is created or compiled)

More info about RegexOptions.Compiled
https://stackoverflow.com/questions/513412/how-does-regexoptions-compiled-work

[ullmark]

Hi there,
Yes, I'm aware that using RegexOptions.Compiled slows the initialization down but speeds up the execution of the regex. You are totally right that those two regex are created unnecessary, good catch. I would guess that most people that use the library doesn't use the hex-functions...

I'll just need to verify that we still can compile for all the targets like CoreCRL etc with Lazy-instantiation. ...Otherwise we can use build directives.

A little backstory is that this library was initially almost a line-to-line port of the ruby and javascript libraries so many things are the way they are because that is how they were written in those languages. Since then we have have been adding more and more C# specific stuff. (Like Int64 support etc..)

[MarcosMeli]

ullmark, great !!

Yes Lazy<> compiles and works in 3 targets. All the tests pass.

I will try to do some perftesting and upload results but the library works really fast.

I think that is super easy to replace the other two Regex because only replace items in guards and seps to " ", we can create a StringBuilder and iterate over the chars replacing guards and seps for " " so the library became Regex free

Thanks
Marcos

[ullmark]

Great! yup, not using regex seems like it would be possible. (those regexes are also there because that is the way it worked in the in the ported library. It has been a bit back and forth whether I wanted to wander away from the way the javascript-library works because at the same time I wanted to make it easy to incorporate any changes in the public api that they made)

re: perftesting. that would be nice, I've googled a bit for good frameworks/tooling to make performance tests in .NET but haven't really found anything super useful. I guess using Stopwatch works, but would be nice to be able to compare more easily.

[MarcosMeli]

We are in the same line, I guessed that the Reges was there to make it similar to the originar version, I think we can add some robust testing before the changes.

About the perf framework we can go this way: https://www.hanselman.com/blog/BenchmarkingNETCode.aspx ( The getting started looks like that we need: https://perfdotnet.github.io/BenchmarkDotNet/GettingStarted.htm)

I must add some of these to the FileHelpers project and can start helping you here too,

Let me know if you wanna do that too

Best Regards
Marcos

[ullmark]

this has been uploaded to nuget. v.1.2.2