Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Support any Display, not just &str #101

Open
epage opened this issue Mar 13, 2024 · 1 comment
Open

Support any Display, not just &str #101

epage opened this issue Mar 13, 2024 · 1 comment
Labels
C-enhancement Category: enhancement

Comments

@epage
Copy link
Contributor

epage commented Mar 13, 2024

This is split out of #13 (comment)

Input text doesn't have to be &str; it can be anything that can implement Display. This is especially useful when the origin source #12 (comment), so the intermediate allocation doesn't have to happen. Playing with take-two I think this dyn has negligible effect on runtime, the real killer to my time is dyn indirection to the span resolvers IIUC.

@epage epage added the C-enhancement Category: enhancement label Mar 13, 2024
@epage
Copy link
Contributor Author

epage commented Mar 13, 2024

I think this would actually hurt performance because we can't directly Display into a location but generally need to do calculations on it, so we'd need to do to_string(), even if its a &str, meaning we'll do more allocations.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
C-enhancement Category: enhancement
Projects
None yet
Development

No branches or pull requests

1 participant