Front page | perl.perl5.porters |
Postings from May 2002
Dave Mitchell [mailto:davem@fdgroup.com] wonders, based on an inquiry from Delta, > * Freeing the 1M scalars does take an *awfully* long time - > is this Perl's fault or malloc()'s - or is that Life? > > Dave. I've worked with a number of different operating-system-supplied storage allocators over the years. They all make the basic assumption that the caller is allocating a "reasonable" amount of storage and holding onto it for a "reasonable" length of time. When you have algorithms that purposefully violate either of these "reasonable" preconditions, you can beat the performance of said allocator by writing your own. But then, you are off in the exciting world of dealing with all of the unreasonable behavior requested by the universe of callers. The allocator we use on VOS allocates storage that is at least 64-byte aligned. We allocate in units of 16 bytes. We have a 16-byte overhead for each block. We have to mask and unmask interrupts on every allocation to protect against program interrupts. We have to be careful in case the heap is damaged. Allocation and free performance is a goal, but is outweighed by correctness, reliability, nonfragmentation, and alignment goals. (By aligning the data properly we optimize the performance of our clients). The short answer is that 1M of anything is expensive. The long answer is that allocating storage is a nontrivial operation. If you want to store a million bytes efficiently, allocate a million-byte string and use substr. Any good algorithms course and / or textbook goes into great depth on these subjects and should be read and studied by any software engineer. This is just the tip of the icebert. Go get a good book and read it, or find a local college and take their algorithms course. HTH PGThread Previous | Thread Next