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 [EMAIL PROTECTED] (personal) [EMAIL PROTECTED] (work) http://www.qaya.org/
