Shrinky-dink Python (also, non-Unicode Python build is broken)

[Giovanni Bajo]

Neil Hodgson wrote:

>> - There will be some opposition to the obvious policy of "keeping
>> the bare minimum inside the DLL" because of inefficiencies in the
>> Python build system.
>
>     It is also non-optimal for those that do want the full set of
> modules as separate files can add overhead for block sizing (both on
> disk and in memory, executables pad out each section to some block
> size), by requiring more load-time inter-module fixups

I would be surprised if this showed up in any profile. Importing modules can
already be slow no matter external stats (see programs like "mercurial" that,
to win benchmarks with C-compiled counterparts, do lazy imports). As for the
overhead at the border of blocks, you should be more worried with 800K of CJK
codecs being loaded in your virtual memory (and not fully swapped out because
of block sizing) which are totally useless for most applications.

Anyway, we're picking nits here, but you have a point in being worried. If I
ever write a PEP, I will produce numbers to show beyond any doubt that there is
no performance difference.

> , and by not
> allowing the linker to perform some optimizations. It'd be worthwhile
> seeing if the DLL would speed up or shrink if whole program
> optimization was turned on.

There is no way whole program optimization can produce any advantage as the
modules are totally separated and they don't have direct calls that the
compiler can exploit.
-- 
Giovanni Bajo