-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Option to use Text instead of String #14
Comments
Has anyone (you, for example) run into performance issues using this library? Parameterizing on the string type would, at best complicate the library, and at worst be a breaking change for little gain. |
Well, I haven't used this library yet. I'm considering to use it over wl-pprint-text, but wouldn't like to have to switch to something more performant, but lacking in features, once problems show up. Than being said, I have witnessed performance problems with generating C code caused by usage of the pretty package. It's somewhat apples to oranges comparison since, although it uses Strings, it renders documents strictly, which forces resulting string to be allocated in full in memory. For the sake of argument, simple switch from pretty to wl-pprint-text gave 50% speedup on particularly large code generation test cases, which is no little gain. Again, even though they're the standard as of now, Strings that use 20 to 40 bytes per character, depending on your platform, do not look very appealing in general. I would very much prefer Text or ByteStrings over linked lists of characters. Finally, parameterizing the library can be done in fully backwards-compatible fashion: add new modules that provide Text-based or some other kind of interface and leave current module a specialization of those to Strings. |
Rather than parametrize the library, which seems pretty gross to me, how about we just eliminate most of its internal use of String and try to preserve the underlying efficient representations as long as possible, such as the below patch? I think this approach is viable because the only thing we do with the Strings is print them out and take their length (once, caching the value for reuse in layout computations); if we can take the length of the efficient form without converting to String, then we'll delay conversion to printout.
|
@sergv if you have particular benchmarks you care about, I'd be curious to see how they behaved before and after the above patch. :) |
@nwf sounds reasonable. |
I think it could be useful to move the library to, or at least give users an option of using, Text akin to https://github.com/ivan-m/wl-pprint-text. The reason is that String may get pretty inefficient memorywise for printing large Docs.
Maybe parameterizing Doc with underlying string type would help?
The text was updated successfully, but these errors were encountered: