News

News

RSS feed
09/06/2020
Krystian's August Update

Boost.JSON Boost.JSON is officially scheduled for review! It starts on September 14th, so there isn’t much time left to finish up polishing the library – but it looks like we will make the deadline. Optimize, optimize, optimize Boost.JSON’s performance has significantly increased in the past month. The change to the parsing functions where we pass and return const char* instead of result (detailed in my last post) was merged, bringing large gains across the board. After this, my work on optimizing basic_parser was complete (for now…), save for a few more minor changes: The handler is stored as the first data member as opposed to passing a reference to each parse function. This means that the this pointer for basic_parser is the this pointer for the handler, which eliminates some register spills. The parser’s depth (i.e. nesting level of objects/arrays) is now tracked as max_depth - actual_depth, meaning that we don’t have to read max_depth from memory each time a structure is parsed. parse_string was split into two functions: parse_unescaped and parse_escaped. The former is much cheaper to call as it doesn’t have to store the string within a local buffer, and since unescaped strings are vastly more common in...

Continue Reading
09/01/2020
Richard's August Update

New Debugging Feature in Asio and Beast As covered previously, Boost 1.74 brought an implementation of the new unified executors model to Boost.Asio. Support for this is not the only thing that is new in Beast. Chris Kohlhoff recently submitted a PR to Beast’s repository demonstrating how to annotate source code with the BOOST_ASIO_HANDLER_LOCATION macro. I have since followed up and annotated all asynchronous operations in Beast this way. In a normal build, there is no effect (and zero extra code generation). However, defining the preprocessor macro BOOST_ASIO_ENABLE_HANDLER_TRACKING will cause these macros to generate code which will emit handler tracking log data to stdout in a very specific format. The output is designed to describe the flow of asynchronous events in a format suitable for generating a visualisation in linear terms. i.e. the asynchronous events are flattened and linked to show causality. Here is an example of the output: @asio|1597543084.233257|>33| @asio|1597543084.233273|33|[email protected] @asio|1597543084.233681|33^34|in 'basic_stream::async_write_some' (../../../../../../boost/beast/core/impl/basic_stream.hpp:321) @asio|1597543084.233681|33^34|called from 'async_write' (../../../../../../boost/asio/impl/write.hpp:331) @asio|1597543084.233681|33^34|called from 'ssl::stream<>::async_write_some' (../../../../../../boost/asio/ssl/detail/io.hpp:201) @asio|1597543084.233681|33^34|called from 'http::async_write_some' (../../../../../../boost/beast/http/impl/write.hpp:64) @asio|1597543084.233681|33^34|called from 'http::async_write' (../../../../../../boost/beast/http/impl/write.hpp:223) @asio|1597543084.233681|33^34|called from 'http::async_write(msg)' (../../../../../../boost/beast/http/impl/write.hpp:277) @asio|1597543084.233681|33*34|[email protected]_wait @asio|1597543084.233801|33^35|in 'basic_stream::async_write_some' (../../../../../../boost/beast/core/impl/basic_stream.hpp:373) @asio|1597543084.233801|33^35|called from 'async_write' (../../../../../../boost/asio/impl/write.hpp:331) @asio|1597543084.233801|33^35|called from 'ssl::stream<>::async_write_some' (../../../../../../boost/asio/ssl/detail/io.hpp:201) @asio|1597543084.233801|33^35|called from 'http::async_write_some' (../../../../../../boost/beast/http/impl/write.hpp:64) @asio|1597543084.233801|33^35|called from 'http::async_write' (../../../../../../boost/beast/http/impl/write.hpp:223) @asio|1597543084.233801|33^35|called from 'http::async_write(msg)' (../../../../../../boost/beast/http/impl/write.hpp:277) @asio|1597543084.233801|33*35|[email protected]_send @asio|1597543084.233910|.35|non_blocking_send,ec=system:0,bytes_transferred=103...

Continue Reading
08/01/2020
Richard's July Update

Boost 1.74 - Progress Update Boost 1.74 beta release has been published and the various maintainers are applying last-minute bug fixes to their libraries in readiness for the final release on 12th August. For us in the Beast team, a fair amount of attention has been spent monitoring last minutes changes to Asio, as Chris makes the final tweaks after the Unified Executors update I mentioned in last month’s blog. Comprehensive Testing Last month I committed what I hoped would be the first of a suite of Dockerfiles which help the mass testing of Beast. The upstream changes to Asio were a lesson in just how many compilers, hosts and target environments we have to support in order that our user base is not surprised or impeded as a result of compiler selection or imposition. I am not expert is Docker matters. I mean, I can read the manual and follow basic instructions like anyone else, but I was hoping that someone would come along to help flesh out the suite a little. Particularly for the Windows builds, since I have no experience in installing software from the command line in Windows, and the greatest respect for those individuals who...

Continue Reading
08/01/2020
Krystian's July Update

What I’ve been doing I’ve been spending a lot of time working on optimizing the parser; perhaps a bit too much. Nevertheless, it’s very enjoyable and in doing so I’ve learned more than I could hope to ever learn in school. In addition to the optimization, comment and trailing comma support finally got merged, and I implemented UTF-8 validation (enabled by default, but it can be disabled). UTF-8 validation Prior to implementing this extension (or rather, feature which can be disabled), the parser considers any character appearing within a string to be valid, so long as it wasn’t a control character or formed an illegal escape. While this is fast, it technically does not conform to the JSON standard. As per Section 2 of the JSON Data Interchange Syntax Standard: A conforming JSON text is a sequence of Unicode code points that strictly conforms to the JSON grammar defined by this specification. As with most standardese, this particular requirement for conformance is not outright stated, but rather implied. Anyways, that’s enough standardese talk for this post. After working on this parser so much, I’ve pretty much got the suspend/resume idiom we use nailed down, so integrating it with the string...

Continue Reading
07/01/2020
Krystian's May & June Update

Overview I’ve been very busy these last two months getting Boost.JSON ready for release, hence the combined blog post. Now that things are winding down, I hopefully can get back the normal blog release schedule. Boost.JSON Aside from a couple of personal projects, the vast majority of my time was spent getting Boost.JSON set for release. Breaking it down, this consisted of three main tasks: a tag_invoke based value conversion interface, parser optimizations, and support for extended JSON syntax. Value Conversion Our previous interface that allowed users to specify their own conversions to and from value proved unsatisfactory, as it required too much boiler-plate when specifying conversions to and from non-class types (e.g. enumeration types). To remedy this, I was tasked with implementing an ADL solution based on tag_invoke which greatly reduces the amount of boiler-plate and provides a single, straightforward way to implement a custom conversion. For example, consider the following class type: struct customer { std::string name; std::size_t balance; }; To convert an object of type customer to value, all you need is to write an overload of tag_invoke. This can be implemented as an inline friend function within the class definition (thus making it visible to ADL...

Continue Reading