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.
