Leonid Pauzner wrote: > Three patches aginst GridText.c attached > (please check whether uuencoded patches now applyed cleanly).
All apply cleanly! > patch #1: bela.dif > changes proposed by Bela Lubkin, to optimize ALLOC_IN_POOL macro > substitution, pack bitfields in HTStyleChanges more compact on some systems. > Applied against clean dev.11 in either way. This is the only one of the three patches that I've actually attempted to analyze. It's true that it implements some suggestions of mine, but not the main one, which was that I still think that ALLOC_IN_POOL should be a function, not a macro. It's a lot of code to be duplicating. It would require a little work to preserve the type polymorphism, but not much (as long as you're willing to restrict the polymorphism to the types you already intend to use it with). Large macros are generally performance-negative. Once upon a time it may have been a win to avoid the overhead of establishing a call frame, doing a call and return, etc. Those times are gone. Now the interesting factors are things like: is this code hot in the CPU cache? If it's a function, only one copy has to be hot in the cache, so your cache footprint is smaller. Your code is less likely to be pushed out by something else; something else is less likely to be pushed out by you. At about the same level: does the CPU's branch prediction table remember how the decisions went last time through this code? Not if you've scattered copies of the same code all over the place -- it has no clue that they're from the same source, have the same basic behavior patterns. Next level up: are the virtual address translations for the pages that contain your code (one copy as a function, or many as a macro) in the CPU's TLB? Are the pages themselves in core or do they have to be paged in from the executable image? How big is the image itself? Will paging these pages in cause some of your own data pages to be swapped out; will you get in a fight with some other process, trading control of certain physical memory pages back and forth? Macros that contain significant amounts of code thwart many levels of hardware optimization. >Bela< ; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to [EMAIL PROTECTED]
