Add from_path and from_string variants that don't buffer output
#86
Conversation
A `Serializer` now receives an instance of `std::io::Write`. This means that we can no longer write the UTF-8 BOM nor the `@charset "UTF-8" directive when serialization is done and instead do the ASCII-content check while visiting the AST. All `inspect_*` methods now create a temporary buffer and pass it to a `Serializer`. Then they (unsafely) interpret the buffer as a UTF-8 string. The goal is to avoid this extra set of allocations and always write directly to the writer passed by the API user. We also removed some extra allocations marked with todo comments.
This also adds a public API to write the output of a compiled set of SASS files into a `Write`. We should add a recommendation to the rustdoc about passing a buffered writer; otherwise performance will probably be horrible. The previous `String`-based APIs were also moved to this new set of APIs by creating a temporary `Vec<u8>` buffer, passing it to the serializer, and finally (unsafely) reinterpreting the buffer contents as a UTF-8 string.
|
Thank you for this change and opening this PR. I'm realizing now that the serialization code could use some more work, and this is an interesting step towards fixing some of that up. I quite like the Do you have a particular use-case that relies on being able to write to an arbitrary For the For the Even if your computer is slow, you might still be able to run benchmarks and profiles. For benchmarking, I usually use If you find your computer is still too noisy to benchmark reliably, I do all of my benchmarking and profiling on dedicated virtual machines which I SSH into. The pricing is quite reasonable and they're very easy to set up and tear down. For profiling I primarily use |
|
Hello, Thank you again for your contribution. I am closing out this PR as it seems inactive, but please feel free to re-open at any time. If you're able to expand on your use case for accepting a |
Makes the
SerializerAPI take an instance ofstd::io::Writewhere the serialized contents are written, instead of placing them in an internal buffer that is then converted to aString.Moves the ASCII-detection code to the visitor API, where we can check for non-ASCII characters only in the relevant places: strings, selectors and units. This also means that the
finishmethod no longer performs a memory copy of the entire serialized output when a non-ASCII character is detected.Other miscellaneous changes include removing some allocations in the
visit_calculation,write_commentandvisit_stmt(in particular, the code in charge of writing aKeyframesRuleSet) methods.The current APIs create a buffer, pass it to a new serializer instance, and finally interpret the buffer's contents as a UTF-8 string. The new public compiler functions
write_from_pathandwrite_from_stringwork exactly in the same manner, but take an (ideally buffered) writer as their last argument.This passes all tests run by executing
cargo teston the main directory, but I'm not sure if I missed another test suite present in the repo. My computer is far too slow to run any benchmarks, but I suspect this changeset should speed up the serialization stage considerably.