About varocarbas.com

--

About me

--

Contact me

--

Visit customsolvers.com, another side of my work

--

Valid markup

--

Valid CSS

--

© 2015-2017 Alvaro Carballo Garcia

--

URL friendly

--

Optimised for 1920x1080 - Proudly mobile unfriendly

R&D projects RSS feed

All projects in full-screen mode

PDFs:

Project 10

Project 9

Project 8

FlexibleParser code analysis:

UnitParser

NumberParser

Tools:

Chromatic encryption

(v. 1.3)

Pages in customsolvers.com:

Upcoming additions

Failed projects

Active crawling bots:

Ranking type 2

(
)

Currently active or soon to be updated:

Domain ranking

FlexibleParser (DateParser)

NO NEW PROJECTS:
Project 10 is expected to be the last formal project of varocarbas.com. I will continue using this site as my main self-promotional R&D-focused online resource, but by relying on other more adequate formats like domain ranking.
Note that the last versions of all the successfully completed projects (5 to 10) will always be available.
PROJECT 7
Completed (47 days)

Improvements >

Irrelevant issues

Completed (19 days)
Completed (14 days)
First contact with open .NET
Completed on 13-Feb-2016 (47 days) -- Updated on 19-Nov-2016

Project 7 in full-screenProject 7 in PDF

I have a relevant expertise improving (the performance of) random algorithms and C# is one of my favourite languages; I do have limited unmanaged-C# experience, but as already explained this shouldn't be a problem. Despite of all that, I did find some difficulties while working on this optimisation; even various issues whose effect on performance (i.e., shorter/longer execution time of a standalone application including the modified version of ParseNumber) was different than expected. On the other hand, this is a more or less logical consequence of the true motivation behind the current optimisation process: my previously-recognised extra-motivation to get a good enough result no matter what.

Below these lines, I am including a list of modifications of the original code which were proven to not have a positive effect on performance.
  • The immediate idea coming to my mind after first seeing the code was replacing the option binary operations (e.g., (options & NumberStyles.AllowLeadingWhite) != 0) with variables, because their values never changed. Binary operations are certainly quick, but wouldn't it be quicker to rely on a variable rather than performing the same operation various times? This assumption was proven wrong: creating a new (NumberStyles or even Boolean) variable is slower than the original version, where binary operations are performed every time. Additionally, relying on updated-in-each-iteration variables to store state binary operations (e.g., (state & StateSign) == 0) isn't a good idea either.
  • I also tried the approach in the previous point with constants. For example: const Int32 StateParens2 = -0x0003 to convert state &= ~StateParens into state &= StateParens2. This time, getting a worse performance was less surprising; the only chunks of code allowing such a configuration, the aforementioned one and state |= StateSign | StateParens, aren't too relevant (i.e., virtually no time is spent there in any input scenario).
  • The aforementioned ideas are not applicable to non-binary operations. For example: replacing all the occurrences of bigNumber with its (sb != null) equivalence is slower.
  • There was a specific modification which seemed to deliver a better performance in the first tests, but which was finally proven inadequate (i.e., indifferent from a performance point of view and, consequently, not part of the modifications to be pulled). It consisted in replacing the char variables with their int equivalences, but only when being involved in mathematical operations. For example: converting ch >= '0' && ch <= '9' into ch >= 48 && ch <= 57.