Re: [PATCH] Re: 2.0 performance Re: Breaking something? Now is the time?

2002-06-30 Thread Brian Pane
Cliff Woolley wrote: On Sat, 29 Jun 2002, Brian Pane wrote: I tried this, and it didn't unroll the loop. That's probably because some of information needed to unroll the loop effectively is unknown to the compiler. Hm. Okay, well, if we're going to do this, can we split it out into a

[PATCH] apr_file_setaside

2002-06-30 Thread Brian Pane
This patch adds an apr_file_setaside() function that moves an apr_file_t from one pool to another without doing any dup(2) or mmap(2) operations. The motivation behind this is to provide the foundation for setting aside small files in core_output_filter()'s keepalive code without having to read

Re: [PATCH] apr_file_setaside

2002-06-30 Thread Cliff Woolley
On Sat, 29 Jun 2002, Brian Pane wrote: This patch adds an apr_file_setaside() function that moves an apr_file_t from one pool to another without doing any dup(2) or mmap(2) operations. Why not keep the dup() and add in a transfer ownership feature like the mmap dup uses? After all, the whole

Re: [PATCH] apr_file_setaside

2002-06-30 Thread Brian Pane
Cliff Woolley wrote: On Sat, 29 Jun 2002, Brian Pane wrote: This patch adds an apr_file_setaside() function that moves an apr_file_t from one pool to another without doing any dup(2) or mmap(2) operations. Why not keep the dup() and add in a transfer ownership feature like the mmap dup

Re: [PATCH] apr_file_setaside

2002-06-30 Thread Cliff Woolley
On Sat, 29 Jun 2002, Brian Pane wrote: Which dup() do you mean: the dup(2) or the naming convention of using _dup*() for this family of apr_file_t functions? Sorry, I should have been more precise. apr_file_dup() was what I was referring to. On second thought though, I suppose I wouldn't

Re: [PATCH] apr_file_setaside

2002-06-30 Thread Brian Pane
Cliff Woolley wrote: On Sat, 29 Jun 2002, Brian Pane wrote: Which dup() do you mean: the dup(2) or the naming convention of using _dup*() for this family of apr_file_t functions? Sorry, I should have been more precise. apr_file_dup() was what I was referring to. On second thought though,

Re: [PATCH] apr_file_setaside

2002-06-30 Thread Cliff Woolley
On Sat, 29 Jun 2002, Brian Pane wrote: #define apr_mmap_setaside(new, old, pool) apr_mmap_dup(new, old, pool, 1); /* the '1' at the end is the transfer ownership flag +1, sounds good. --Cliff

Re: [PATCH] Re: 2.0 performance Re: Breaking something? Now is the time?

2002-06-30 Thread Ben Laurie
Cliff Woolley wrote: On Sat, 29 Jun 2002, Cliff Woolley wrote: some way that would allow us to coalesce the writes. Alignment issues would kill us here, aren't they? That sucks. G. Depends on the CPU, but if you are feeling energetic you can also align the copies. The problem is