From: Peter Kirk (email@example.com)
Date: Thu Oct 16 2003 - 15:48:47 CST
On 16/10/2003 11:20, John Hudson wrote:
> At 12:26 AM 10/16/2003, Doug Ewell wrote:
>> Peter Kirk <peterkirk at qaya dot org> wrote:
>> > Does everyone agree that "This is not a performance issue"?
>> You can never tell whether something is going to be a "performance
>> issue" -- not just "measurably slower," but actually affecting
>> usability -- until you do some profiling. Guessing does no good.
> And does everyone agree on that definition of 'performance issue'?
> I've spoken with text processing engineers who certainly consider
> 'measurably slower' to be a 'performance issue', especially if that
> decreased speed is noticeable to users who do not benefit from changes
> to existing software. For example -- knowing that it is on Peter's
> mind -- if an existing Hebrew text engine is modified to be able to
> correctly render normalised Biblical Hebrew -- e.g. by buffered
> re-ordering of characters from normalised order to an order that can
> be processed by fonts -- is the measurably slower performance an
> acceptable performance hit *if* your priority is modern Hebrew text
> processing that does not require such re-ordering. ...
Why should it be a performance hit for modern Hebrew? Most modern Hebrew
is unpointed, which means that it has no combining characters, and so
any reordering routines would never be triggered. In rare cases there
may be single combining characters, but as John Cowan realised there is
no need to call a sort routine to sort a single character. The sort
routines need only be called when they are needed.
Asmus mentioned a composition phase in producing NFC. This is not
actually relevant to Hebrew either as there are no precomposed
characters, apart from the alphabetic presentation forms which are
composition exceptions. A rendering system might actually choose to use
those APFs, but that is a separate issue.
-- Peter Kirk firstname.lastname@example.org (personal) email@example.com (work) http://www.qaya.org/
This archive was generated by hypermail 2.1.5 : Thu Jan 18 2007 - 15:54:24 CST