On Mon, 2004-05-17 at 18:07, Ben Reser wrote:
> Maybe in some cases he'd be right. But in this case we're allocating
> the memory in the for loop, which means we're allocating and freeing
> memory on each pass of the loop. This particular loop happens to
> iterate over every file in a working copy.
I can't help but suspect that you misunderstand how stack variables are
allocated. It doesn't take any more time to "allocate" two stack
variables than it takes to allocate one, and frequently it takes no time
whatsoever. The space used, if we make any function calls from within
the for loop, is supremely unimportant; we never use a substantial
amount of stack space.
Cycle counting, even when it's done properly (which it usually isn't),
is worse than useless in the vast majority of situations. Subversion's
perceived speed will never have any dependence on whether we use a few
more or less instructions per file in the working copy. When our
performance is bad, it's because of our architectural decisions and our
algorithms, not because of micro-optimization concerns (with the
possible exception of the vdelta code).
> At any rate, r9757 fixes this.
I think you were jousting at windmills there. What's wrong with mixing
stack and heap storage for a short-lived, read-only pointer?
Option-parsing loops mix storage types all the time (opt.field might
point to a string literal, or to a component of argv).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue May 18 01:15:52 2004