Ove Kaaven <[EMAIL PROTECTED]> writes: > Not that much. Wine's allocator already implements the *features* of that > allocator (boundary tags, bins), it just doesn't implement all the > *strategies* used for selecting which free block to allocate memory from > (though the only big things we lack there is "best fit" and "wilderness > preservation", the latter of which Alexandre talked about).
Well, we do have (almost) best fit, that's the only reason for having multiple free lists. It's just that we probably need more bins sizes to make it really useful. > We just need > to make sure Wine's free block selection routine uses the same strategies > as this allocator, and we'd get exactly the same performance as that > allocator, but without replacing the whole thing and sacrificing the > compatibility we have or introducing new bugs. Well, this depends how easy it is to plug the new allocator in; but if it doesn't require too many changes, it will certainly introduce less bugs than trying to tweak the existing code. Plus all the profiling work has been done already, which would have to be done on the Wine code. -- Alexandre Julliard [EMAIL PROTECTED]
