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)

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)

Code overview >

Methods

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

As explained in the first section, I got a quite good impression about the overall quality of the open .NET code (i.e., not just in CoreCLR, but also in CoreFX and Roslyn): very clear structure, efficient algorithms, descriptive comments, etc. All the parts analysed here (i.e., various methods in the file Number.cs) are certainly not an exception to this statement.

This project is focused on the optimisation of ParseNumber and associated resources. All its code is written in (almost-exclusively-)unmanaged C#, although C++ is also used in Number.cs even in parts which are closely related to ParseNumber. The following three different methods will be considered:
  • Boolean ParseNumber(ref char* str, NumberStyles options, StringBuilder sb, Boolean parseDecimal): it analyses the inputs to the given parsing method, like Decimal.Parse (i.e., string to be converted into number and arguments taking care of Additional issues, like culture-related format); then outputs the numerical characters which will be later transformed into the given type (i.e., decimal) by NumberBufferToDecimal. All this code is unmanaged and highly optimised (e.g., relevant usage of bitwise operations). Most of the performance-improvement modifications of this project were precisely done to this method.
  • char* MatchChars(char* p, char* str): it is called from ParseNumber, while looping through the characters in the input string, and returns the position after the given target (str). There is a second overload (char* MatchChars(char* p, string str)) allowing the target to also be string.
  • Boolean IsWhite(char ch): very simple method checking whether the given character is blank. Anecdotally and unlikely the two aforementioned methods, this is managed code.
Ideally, this algorithm should be optimised by completely rethinking how the problem is being faced; specifically, the not-too-practical/efficient way in which the input information is stored provokes unnecessary problems. For example: over-complicated/less-efficient algorithms or over-usage of resources (e.g., most of potential inputs aren't analysed). Nevertheless, such an expectation is beyond the scope of the current project and its final goal (i.e., pull request to CoreCLR, whose likelihood to be accepted would be much lower in case of including modifications in existing features). The decimal.TryParseExact method which I am planning to create in the near future (likely to be part of Project 9) will certainly take care of these issues, also account for various functionalities not supported by the current parsing approaches.