-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
Improve the annotated join method and dispatch #51914
Conversation
454e7e9
to
7e55049
Compare
Now that the prerequisite PRs have been merged 🥳, we can now think about merging this one. |
looks good to me |
7e55049
to
4dd043e
Compare
Huh, I see CI actually wasn't happy. I pulled the latest changes in CI should be happy now 🤞, and I presume this would be good to merge then? |
I'm a bit confused by the fact that CI is showing errors that I don't see locally, namely:
when if I do
|
This seems somewhat a lack of a complete |
When you're using the REPL, and styling attributes, I find that the current but yes, this is annoying when looking at it in CI. For CI alone, displaying the value like the constructor ( |
Would having a different |
For now I'll temporarily change the |
4dd043e
to
239087c
Compare
This is stange. After adding the logging, it's not complaining about the difference anymore (I just see doctest failures resulting from the log-more-info change). Was it fixed by rebasing to a newer |
With the initial implementation, join could work for AnnotatedStrings, however only when the eltype of the iterator or delim was itself a Annotated{String,Char}. This was better than nothing, but seems inconsistent in the face of mixed iterators. Furthermore, the implementation of an annotated join was far from optimised, relying on zipping and then calling annotatedstring(xs...). By contrast, the non-annotated implementation relies on printing to IO and even has manually defined alternative methods for optional arguments to minimise code generation. With the advent of AnnotatedIOBuffer and _isannotated, we can improve on both those aspects. The new AnnotatedIOBuffer type allows us to re-use the optimised join(::IO, ...) methods, and we can more reliably dispatch to them with _isannotated. Since this is a type-based decision, the Julia compiler is kind enough to work out which branch is taken at compile-time, making this zero-overhead in the unannotated case.
239087c
to
024af3e
Compare
Tests have successfully run on everything but the Mingw32 Windows builds. I think this is good to go now. |
With the initial implementation, join could work for AnnotatedStrings, however only when the eltype of the iterator or delim was itself a Annotated{String,Char}. This was better than nothing, but seems inconsistent in the face of mixed iterators.
Furthermore, the implementation of an annotated join was far from optimised, relying on zipping and then calling annotatedstring(xs...). By contrast, the non-annotated implementation relies on printing to IO and even has manually defined alternative methods for optional arguments to minimise code generation.
With the advent of AnnotatedIOBuffer and _isannotated, we can improve on both those aspects. The new AnnotatedIOBuffer type allows us to re-use the optimised join(::IO, ...) methods, and we can more reliably dispatch to them with _isannotated. Since this is a type-based decision, the Julia compiler is kind enough to work out which branch is taken at compile-time, making this zero-overhead in the unannotated case.
Depends on #51806 and #51807