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.
