Skip to content
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

optim: Store indices instead of making new SmartStrings #9

Open
cdown opened this issue May 10, 2023 · 1 comment
Open

optim: Store indices instead of making new SmartStrings #9

cdown opened this issue May 10, 2023 · 1 comment

Comments

@cdown
Copy link
Owner

cdown commented May 10, 2023

About ~12% of time is spent in doing conversions from &str to SmartString, which may require a reallocation anyway.

  1. https://github.com/bodil/smartstring/blob/e407ca23c747257a812d2d2e70bf336412718c3a/src/lib.rs#L646
  2. (or if inline): https://github.com/bodil/smartstring/blob/e407ca23c747257a812d2d2e70bf336412718c3a/src/inline.rs#L83

Maybe we can just store the indices instead of converting to and from SmartStrings? We only need a Borrowed anyway at self.get() time. No idea if it would actually be faster.

@cdown
Copy link
Owner Author

cdown commented May 10, 2023

Oh, we do actually need key later as part of error reporting. Hmm.

I wonder if this in general would be better encapsulated with a single Formatter struct that holds format pieces (at first an empty Vec, populated on first run), formatters, and the format string. Then we could safely hold on to the &str because we still have the backing format string in this struct.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant