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

(
)

FlexibleParser raw data:

Unit conversion (UnitParser)

Compound types (UnitParser)

Timezones (DateParser)

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 >

Final version

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

This whole project has become much more complex than initially expected. The most difficult part was coming up with a reliable and overall-applicable testing framework to accurately measure the performance variations. Nevertheless, the results of this extra-effort are certainly worthy: not only a more efficient ParseNumber version, but also lots of relevant insights about performance improvement (comparison and testing) under very demanding conditions.

I did come up with the first good enough version of the new code relatively quickly, but didn't make the final decision about certain parts until after all the tests were completed. In fact, I found various issues whose almost irrelevant effect on performance was kind of surprising to me; all of them are mentioned in the previous section.

The last version of the modified code (i.e., the one in my pull request to CoreCLR) includes various changes in ParseNumber and in the second MatchChars overload with respect to the original version. The table below these lines includes a reference to each of them, together with a % estimation of its contribution to the overall improvement (as defined in the last section of the Tests part).

ModificationContribution (%)
altdecSep & altgroupSep removal40
signflag removal30
Redefinition of IsWhite(ch)-headed conditions12
Redefinition of MatchChars(char* p, char* str)11
bigNumberHex removal7


All the aforementioned modifications refer to variable and method names present in the original version of the code. The justification for all these improvements should be more or less evident, except perhaps the bigNumberHex removal. Note that this modification implies to remove a Boolean variable (bigNumberHex) by replacing it with the less-efficient chunk of code (bigNumber && ((options & NumberStyles.AllowHexSpecifier) != 0)). Such a trade-off is positive because of happening in a part which is rarely used (i.e., all the benefits of removing one variable, but almost none of the slower-code drawbacks). Note that bigNumberHex is only used with hexadecimal inputs (i.e., a not-too-likely scenario); and even in this situation, exclusively with the non-numerical characters (note that a hexadecimal value might consist only in numbers). Thus, the affected condition is verified most of the times through the first short-circuited term by ignoring the new slower code.