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)
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

The first conclusion is that meeting the main goal of this project (i.e., improving the performance of ParseNumber & related methods) has been more difficult than expected; as a result of this unplanned-complexity, quite a few relevant outputs have been generated. Examples: various open-source applications (i.e., ParseNumber_Test.exe, ParseNumber_Test2.exe, ParseNumber_Gen.exe, ParseNumber_TestCalcs.exe & ParseNumber_Validation.exe), good insights into the best methodologies to accurately measure time differences between similar programs or more knowledge about performance improvements in unmanaged-C# codes. In general, this has been a very good first experience in open .NET (also my first open-source contributions ever).

Just by looking at the original goal of this project (i.e., more efficient version to be pulled to CoreCLR), the conclusion is that the final result has also been very good: the modified code is clearly quicker (i.e., every time and under all the testing conditions) without affecting the original algorithm at all and without adding any negative issue (e.g., lower readability or scalability).

The whole evolution of this project has also been a good mood-booster (and self-promotion). I chose the first chunk of code I saw in CoreCLR (by pure accident, while pre-analysing my original decimal-related concerns, #2285 and #2290), which happened to be in one of the most basic, old and highly-optimised parts of the whole .NET Framework (i.e., numeric type parsing inside mscorlib.dll). I started this optimisation project even before having analysed the code in depth. Everything gets more complicated than expected, what makes me spend here much more time and effort than originally planned (by bearing in mind that this is a R&D, no-income-generating activity). And as a result of all this, I deliver what, in my opinion, is the most interesting & comprehensive project about programming since this site was created!


OVER-8-MONTH-LATER UPDATE

As explained in similar updates in other sections, this PR was accepted and even provoked modifications in other repositories (i.e., CoreRT and CoreFX versions of the same methods). Although it took quite long (over 8 months), I understand that modifications affecting a so essential part (i.e., used by the Parse/TryParse methods of all the numeric types) cannot be accepted right away. I am certainly happy with how everything went.