in reply to Re^4: Alternative to bytes::length() (7% solution)
in thread Alternative to bytes::length()
I believe that your 'utf8' case is mostly benchmarking the pulling out of the character count cached in the magic, thus completely missing the original problem.
I was mostly concerned with pointing out that it's important to consider exactly what you're benchmarking.
I'm also not convinced that there is enough of a description of "the original problem" to say whether I missed or not. I'm finding it quite hard to think of an application where the time taken to obtain the length of a string would be very significant?
Except maybe when sorting strings by length, at which point the caching would pretty much negate the first-time cost.
I don't see how your benchmark provides any justification for not using eq ''
Um...cos I modified the original benchmark and didn't think about it. Having just swapped the 'ne's for 'eq's, it does make a suprising difference. Though I haven't thought through whether that's down the efficiency of the operator or the change to the boolean logic.
It did surprise me greatly that ord worked out much faster than bytes::length.
|
---|
Replies are listed 'Best First'. | |
---|---|
Re^6: Alternative to bytes::length() (7% solution)
by creamygoodness (Curate) on Dec 23, 2009 at 16:09 UTC | |
by BrowserUk (Patriarch) on Dec 23, 2009 at 16:58 UTC |