apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@attglobal.net>
Subject Re: nasty apr-util xlate bug
Date Mon, 22 Mar 2004 14:45:20 GMT
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.

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.

Mime
View raw message