From: Michael D. Adams (mdmkolbe@gmail.com)
Date: Mon Feb 23 2009 - 11:31:27 CST
I think the point that David is making is that your numbers only show
"optimized performance for the overwhelming majority" and show nothing
about "acceptable performance for everything". Since your two sample
texts don't test out the badly performing areas of "everything", using
only the data presented on your page the reader can not conclude the
latter.
Michael D. Adams
On Mon, Feb 23, 2009 at 10:34 AM, Mark Davis <mark@macchiato.com> wrote:
> Clearly it isn't a good ideal to lock up a machine when when it hits a rare
> character; nobody's saying anything like that. The goal is acceptable
> performance for everything, and optimized performance for the overwhelming
> majority.
>
> Mark
>
>
> On Mon, Feb 23, 2009 at 03:56, David Starner <prosfilaes@gmail.com> wrote:
>>
>> On Mon, Feb 23, 2009 at 1:46 AM, Mark Davis <mark@macchiato.com> wrote:
>> > And that is bad, why? The fact code can be fast-pathed is typically a
>> > key
>> > tool to achieving performance goals.
>>
>> [...]
>>
>> > Measuring inputs that match reality is vital for producing
>> > high-performance
>> > code. Let's take an example. In ICU we routinely maximize for BMP
>> > characters. While someone doing extensive work in cuneiform might be
>> > somewhat slower, the code is faster for the vast majority of cases. So
>> > that
>> > is the right way to code it.
>>
>> If and only if it's "somewhat slower" and not "oh my god why has my
>> computer locked up". Algorithms with awful worst-case scenarios can be
>> the cause for a very frustrating experience for users who aren't
>> considered important by the programmer. And if the program is on a
>> server, no matter how bad and unrealistic the data is, the program
>> must be capable of processing it in a reasonable amount of time,
>> because if not, someone will find it amusing to send it to the
>> program, over and over.
>
>
This archive was generated by hypermail 2.1.5 : Mon Feb 23 2009 - 11:34:17 CST