Vladimir 'Yu' Stepanov wrote: > * To adapt allocation of blocks of memory with other alignment. Now > alignment is rigidly set on 8 bytes. As a variant, it is possible to > use alignment on 4 bytes. And this value can be set at start of the > interpreter through arguments/variable environments/etc. At testing > with alignment on 4 or 8 bytes difference in speed of work was not > appreciable.
That depends on the hardware you use, of course. Some architectures absolutely cannot stand mis-aligned accesses, and programs will just crash if they try to perform such accesses. So Python should err on the safe side, and only use a smaller alignment when it is known not to hurt. OTOH, I don't see the *advantage* in reducing the alignment. > * To expand the maximal size which can be allocated by means of the > given module. Now the maximal size is 256 bytes. Right. This is somewhat deliberate, though; the expectation is that fragmentation will increase dramatically if even larger size classes are supported. > * At the size of the allocated memory close to maximal, the > allocation of blocks becomes inefficient. For example, for the > sizesof blocks 248 and 256 (blocksize), values of quantity of > elements (PAGESIZE/blocksize) it is equal 16. I.e. it would be > possible to use for the sizes of the block 248 same page, as for the > size of the block 256. Good idea; that shouldn't be too difficult to implement: for sizes above 215, pools need to be spaced apart only at 16 bytes. Regards, Martin _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
