apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Orton <...@manyfish.co.uk>
Subject Re: nasty apr-util xlate bug
Date Thu, 25 Mar 2004 22:50:01 GMT
On Mon, Mar 22, 2004 at 09:45:20AM -0500, Jeff Trawick wrote:
> Joe Orton wrote:
> >So it seems no optimisation is really possible here; what performance
> >problem is this code solving?  The overhead of iconv surely in
> >iconv_open() anyway: I think the right thing to do is remove the
> >check_sbcs() functions. 
> On z/OS, where charset translation is a key feature of most network apps, 
> the applications I'm familar with used their own tables for fast lookup 
> when that was safe, and used iconv() otherwise.  I did not do my own 
> performance analysis to see what the real benefits are, but simply assumed 
> this was valuable for some real world scenarios where APR is used, such as 
> Apache on z/OS where lots of data will be translated.  So I put the local 
> table capability down in APR so the app wouldn't have to worry about it.  
> But that has an issue:  APR really doesn't know one charset from another, 
> unlike many apps which constantly deal with 
> some-EBCDIC-codepage<->US-ASCII, so APR doesn't inherently know when a 
> translation is always single-byte and needs to figure it out if it is going 
> to own the optimization task.

Can APR just hard-code a couple of EBCDIC<->something translation tables
(#ifdef I_AM_EBCDIC) to solve these problems?  I'd be suprised if the
iconv() adds that much overhead vs the translation table, if you're
going to do the iconv_open() anyway.

Anyway, you don't disagree that the current code "single-byte
translation detection" code is unsafe and needs to be removed?

> There is also an API simplicity issue.  In some code situations it is nice 
> to have an API that is as simple as an array access (see 
> apr_xlate_conv_byte()), but this makes sense only when it is known that the 
> translation is single-byte. Apache can use this in some common situations 
>  where it is not too much overhead, but it would probably want to maintain 
> its own tables for protocol data conversion in lieu of having to set up 
> calls to the more complicated apr_xlate_conv_buffer() all the time.

View raw message