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

Debug for str writes one byte at a time #26920

Closed
bluss opened this issue Jul 9, 2015 · 3 comments · Fixed by #28662
Closed

Debug for str writes one byte at a time #26920

bluss opened this issue Jul 9, 2015 · 3 comments · Fixed by #28662
Labels
I-slow Issue: Problems and improvements with respect to performance of generated code.

Comments

@bluss
Copy link
Member

bluss commented Jul 9, 2015

The Debug formatter for str outputs one byte at a time to the underlying writer.

We could improve this, for example we could skip forward while no escaping is needed, and if we find a char to escape, write the backlog and then write escape for the current char, and continue.

Exploration impl:

impl Debug for str {
    fn fmt(&self, f: &mut Formatter) -> Result {
        try!(write!(f, "\""));
        let mut write_from = 0;
        for (index, ch) in self.char_indices() {
            // if char needs escaping, flush backlog so far and write, else skip
            let mut escaped = ch.escape_default();
            if let Some(first) = escaped.next() {
                if let Some(second) = escaped.next() {
                    if write_from != index {
                        try!(write!(f, "{}", &self[write_from..index]));
                    }
                    write_from = index + ch.len_utf8();
                    try!(write!(f, "{}{}", first, second));
                    for ech in escaped {
                        try!(write!(f, "{}", ech));
                    }
                }
            }
        }
        try!(write!(f, "{}", &self[write_from..]));
        write!(f, "\"")
    }
}
@steveklabnik steveklabnik added the I-slow Issue: Problems and improvements with respect to performance of generated code. label Jul 9, 2015
@bluss
Copy link
Member Author

bluss commented Jul 10, 2015

Reported a bug to gauge the importance. I'd tackle it, but is it a bug? Worth fixing?

@huonw
Copy link
Member

huonw commented Jul 10, 2015

It seems silly to have unnecessarily slow code hanging around, but if the fixed code is complicated, maybe it's not worth it yet?

@huonw huonw added the A-libs label Jul 10, 2015
@semmaz
Copy link
Contributor

semmaz commented Sep 21, 2015

I'm willing to give this a stab and #24588 while I'm at it, but unsure if this still relevant, or what current opinion on this might be. Should I give a go for these two?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
I-slow Issue: Problems and improvements with respect to performance of generated code.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants