Re: NFC FAQ

From: Mark Davis (mark@macchiato.com)
Date: Mon Feb 23 2009 - 12:01:57 CST

  • Next message: Asmus Freytag: "Re: NFC FAQ"

    The worst performance would be (in the 1M character example I've been
    using), something like a base character followed by a list of 999,999
    characters with CCC != 0, sorted by CCC in reverse order. I added a note to
    this effect.

    Mark

    On Mon, Feb 23, 2009 at 09:31, Michael D. Adams <mdmkolbe@gmail.com> wrote:

    > 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 - 12:04:29 CST