I managed to move connect functionality over, and then it took me no
time to convert sockperf over to new api. with some mods to the app to
allow for more tests per iteration, here are the results.
NB These were done against the same echod running using the current api.
Current API
APR Test Application: sockperf
Tests Complete!
1024 byte block:
100 iterations : Average: 351
4096 byte block:
100 iterations : Average: 472
16384 byte block:
100 iterations : Average: 81524
65536 byte block:
100 iterations : Average: 3422
262144 byte block:
100 iterations : Average: 14361
APR Test Application: sockperf
Tests Complete!
1024 byte block:
100 iterations : Average: 639
4096 byte block:
100 iterations : Average: 632
16384 byte block:
100 iterations : Average: 81753
65536 byte block:
100 iterations : Average: 2009
262144 byte block:
100 iterations : Average: 10227
Revised IO api
APR Test Application: sockperf
Tests Complete!
1024 byte block:
100 iterations : Average: 324
4096 byte block:
100 iterations : Average: 290
16384 byte block:
100 iterations : Average: 83065
65536 byte block:
100 iterations : Average: 2358
262144 byte block:
100 iterations : Average: 10132
APR Test Application: sockperf
Tests Complete!
1024 byte block:
100 iterations : Average: 581
4096 byte block:
100 iterations : Average: 578
16384 byte block:
100 iterations : Average: 83164
65536 byte block:
100 iterations : Average: 2637
262144 byte block:
100 iterations : Average: 12143
NB any idea why the 16k tests are so much slower? Is it an apr issue or
an os one?
Basically the results show the sorts of variations we'd expect I think.
They don't seem to point to truly horrible reduction in IO though.
I think that somehow people aren't really "on the same page" as I am, so
I'll try and explain again what I'm aiming for. When fully implemented
the IO abstraction will allow ANY app to create it's own type of
apr_io_t - which can then be mised/matched with any other type of
apr_io_t within the app. In my imagination the revised apr_ssl code
simply creates apr_io_t's - there is no longer a notion of
files/sockets/pipes or anything else. All the code currently under
network_io and file_io goes away - replaced instead by code unser simply
'io'. The api is extensible - deliberatly so.
I have the headers creating docs, so if people want me to put them
online then I'm happy to do so. They should at least point to how it all
fits together.
This seems to be what is needed and what people want. That's why I
dropped the 'io' from the function names as there shouldn't be a need
for any other forms of these functions. Will's suggestion that you
should be able to call specific functions is utter lunacy with the
abstraction I'm aiming for - if you even care then you're doing
something wrong. That's not to say there aren't functions that will need
to be called directly, but a function apr_xml_config_get(...) is
different to simply reading the file, which would be done by apr_read().
Now,if people don't want this or don't see a need then I'm happy to walk
away and forget it.
david
