Reduce binary size

[glynos]

This is a major change coming in.

In a private correspondence, someone told me that they were not able to use the URI on an embedded project because of the binary size. I measured the size of the libnetwork-uri.a file that we output:

Using Ubuntu 15.10, clang 3.7, boost 1.60

glynos@trillian:~/Development/uri/_build$ ls src/libnetwork-uri.a -l
-rw-rw-r-- 1 glynos glynos 11010822 May  8 18:47 src/libnetwork-uri.a

And optimizing for size (-Os):

glynos@trillian:~/Development/uri/_build$ ls src/libnetwork-uri.a -l
-rw-rw-r-- 1 glynos glynos 1373778 May  8 18:50 src/libnetwork-uri.a

This is considerable for a library that does little more than process a string. The explanation for the size comes from the fact that we use Boost.Spirit to perform the parsing. There are other reasons to move away from Boost.Spirit (the number of source files it pulls in, compile times, the error messages (!)), so I decided just to dive in and write a URI parser from scratch.

Now, I have updated the library so that all existing tests succeed with the new parser. It didn't take as long as I had first feared. It is pretty clean, and does not allocate any memory (apart from the original std::string object). It is faster to run and the compile times are much reduced. And the motivating factor (binary sizes) show that this was the right thing to do:

glynos@trillian:~/Development/uri/_build$ ls src/libnetwork-uri.a -l
-rw-rw-r-- 1 glynos glynos 667262 May  8 18:51 src/libnetwork-uri.a

And optimizing for size (-Os):

glynos@trillian:~/Development/uri/_build$ ls src/libnetwork-uri.a -l
-rw-rw-r-- 1 glynos glynos 183204 May  8 18:51 src/libnetwork-uri.a

That's a 16.5x improvement, and 7.5x with the optimization flag set.

Also, I feel that the new code is much cleaner. You don't need to be Boost.Spirit guru to understand it.

So what would be the downsides to re-writing the parser from scratch (apart from me losing part of a weekend)?

1. Parts of the validation are incomplete - i.e. right now, the new parser is pretty permissive to errors in the host name and path. However, our test suite is fully green and showed no regression. Improvements can be made continuously.
2. I didn't really look at the the other parts of the URI, though I eventually want to redesign these anyway. With one exception, all of the normalization, comparison, and resolution tests passed. The exception is very, very weird though, and I have commented out the offending code for now (on GCC and Clang on my local machine it works, but Travis totally rejects it - see uri.cpp lines 356-361).
3. It doesn't work on MSVC at all. I tried with MSVC 2013, and I don't yet have access to MSVC 2015.

[deanberris]

LGTM

Just to be clear, we're now using a hand-rolled parser. That's good. However, you were measuring a debug build of the library, right? Have you tried a release build to see if the symbols that are exported are still there?

I think it's the right direction and it's better we do this sooner than later.