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


Project 10

Project 9

Project 8

FlexibleParser code analysis:




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)

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

Unexpectedly, I have spent most of my time here by trying to come up with the best approach to measure the performance differences between both methods (i.e., old & new versions of ParseNumber). The fact that the original version was already optimised is the main reason explaining so many difficulties in this in-principle-easy part. Additionally, the optimisation process wasn't precisely straightforward (e.g., I found some of the Irrelevant issues quite surprising), what avoided me to have clear enough ideas regarding the expected measurements (i.e., being sure about the exact effects of certain modification would have been helpful to quickly spot problems with the tests).

Although the basic structure of the main program didn't change appreciably since the start, the whole testing approach (i.e., the C# program, its inputs and the way in which the time differences were measured) had many relevant changes. Roughly speaking, it passed through the following stages:
  • Firstly, I relied on CoreRun.exe because of assuming that this was the best way to emulate realistic conditions. As already explained, this assumption was quickly proven wrong: CoreRun.exe has an important negative (and not consistent) impact on the given .NET executable performance. Nevertheless, CoreRun.exe is used for the last validation stage, where the modified ParseNumber version is tested under as-realistic-as-possible conditions; this is done with ParseNumber_Validation.exe which iterates through the Parse and TryParse methods of various types (i.e., decimal, int, long and double).
  • For my first tests without CoreRun.exe, I relied on two different executables (e.g., new.exe & old.exe). But back then the gap between both approaches wasn't too relevant and running two different programs represented an unacceptable increase in uncertainty. That's why I didn't try this option for too long.
  • Even before moving to the both-in-the-same-file approach, I was aware about the associated increase of uncertainty (i.e., running one method affects the time measurements of the other one). After trying different ways to minimise this influence (e.g., setting different pauses at different points, pre-warming or affecting GC), I confirmed that the most reliable methodology was alternating the order in which the versions were measured (note that I also tested a random-order approach which was proven less reliable).
  • Then I moved back to two different executables; also tried to make the testing algorithm as efficient as possible to confirm whether these effects (i.e., smaller pauses between consecutive calls) had a relevant effect on the observed performance differences. The resulting application was the first version of ParseNumber_Test2.exe, the definitive testing program. There were some relevant changes after this, but all of them are listed in the corresponding section.