> > Can you put in words and some simple examples what's wrong with the API? > > The problem is that it is impossible to do a lot of small writes to a > brigade efficiently. Take as an example, code that needs to add 20 five > byte buffers to brigade. There are two options: > > 1) bigbuff = apr_pstrcat(p, buf1, buf2, buf3, buf4, buf5, ...); > b = apr_bucket_make_pool(p, bigbuff); > APR_INSERT_BRIGADE_TAIL(bb, b); > > 2) b = apr_bucket_make_heap(buf1); > APR_INSERT_BRIGADE_TAIL(bb, b); > b = apr_bucket_make_heap(buf2); > APR_INSERT_BRIGADE_TAIL(bb, b); > b = apr_bucket_make_heap(buf3); > APR_INSERT_BRIGADE_TAIL(bb, b); > ...
Why write to the brigade instead of the top filter? The problem with this type of optimization is that the brigade code cannot know the optimal size of a bucket -- only the next filter in the chain can know, since what is optimal will depend on what kind of processing is done next. I think that if we are suffering from wasted cycles and pallocs due to premature brigade formations, then we should try it the other way -- always allocate the bucket structure off the stack, use a simple next pointer to connect brigades, and force the filter that needs to setaside the data to do so in a way that coalesces the bucket data. That was the main difference between the design we are using now and the one Greg proposed prior to the filters meeting. ....Roy
