>> (I often wonder why software today isn't much faster than years ago -
>> though the nominal speed of hardware increases tremendously. package
>> sizes grow, without appropriate growth of functionality. This is one
>> example how the rescources are wasted too careless.)
> I don't know of any evidence that software slowness has to do with code
> size. When code isn't called, it doesn't pollute the instruction caches
> and hence shouldn't affect execution speed.

With slowness under the subject here I mean long startup time  (and slowness by overall memory impact on small systems like laptops, non-cutting edge hardware, even embedded systems.). Thats what is mainly unpleasant and what seems to not improve appropriately overall. 
Developers carelessly link bigger and bigger libraries which eats the hardware gains ...
There are however some good efforts: For example when Google came out with Chrome (and many after fast responding apps), fast startup time was the striking issue. And the old browsers meanwhile were challenged by that, and improved as well.

Please keep Python fast as well. I'm using it since 1.5.2, and that careless fatty degeneration is one of the main things I don't like. 
Python is a universal language. Most Python progs are small scripts.

Overall I wonder why you post here on the main topic "resource usage", when you don't care about issues of magnitude 2x memory usage. Why not close this topic for Python at all with your arguments?

>
> I understand the concern about py2exe and similar distribution systems
> (although distribution size should be much less important nowadays than
> 10 years ago). But, really, it's a separate issue.

that is not really a separate issue (because module decoupling is a pre-requisite therefor, a sort of show stopper).

And as mentioned its by far not the only issue.

>
>> For example each cgi script (which has to respond fast and does only a
>> small job), which does  "import cgi" and a few lines; or a script
>> which just uses e.g., urllib string format functions ... : the whole
>> thing is drawn.
> Well, CGI scripts are a wasteful way to do programmatic page serving. If
> you care about performance, you should have switched to something like
> FastCGI or mod_wsgi.

And how about other "scripts" ;-) 

I'm sure you find everywhere something how you can make all app programmers busy and not take care of the few cheap fixes mentioned in the system to make Python faster und usable easily for everybody.
I created this issue to improve Python and make experience significantly faster.
You seem to me being too interested in closing issues fast.

>If you care about performance

You have this sort of black-white arguments which are green and somehow really I think, you are perhaps misplaced in this category "resource usage".

>
>>>> Also the linkage of _ssl solely against a detailed version of
>>>> libssl/libcrypto is still questionable.
>>> I don't know the reasons (if any). Perhaps you can open a separate issue
>>> about that?
>> Yet the issue of this library is here now. Why procrastinate?
> This sentence sounds like you want to dictate us what and how we should
> work on. That won't fly, sorry. The reason we want to avoid tackling
> multiple issues in a single tracker entry is simply so that the entries
> stay readable and searchable.
>
> (and, really, most projects' bug trackers work that way, for the same
> reasons)

You are free to divide the issue if you really think its worth multiple.
But why close it swift-handed before that is sorted out / set up? I indeed wonder about that careless style here meanwhile. Its not as it was years ago.

To me this "issues" seem to belong rather so close together, that the possible fix should perhaps be made in one go.

>> (The Debians would have gone rather deep into issues when they really
>> created that fine tuning on their own. almost can't believe.
> There's nothing magical about libssl that would make us link it
> statically to the executable; it's far too optional a dependency for
> that. Perhaps Debian has its own bootstrapping requirements that mandate
> it, or perhaps they simply made a mistake and nobody complained before?
> Why don't you open an issue on their bug tracker, or at least try to
> contact them? You would get a definite answer about it.

So are you definitely saying/knowing, there is really no such mentioned optimized module selection  (~50% of so modules since Python2.5 on Debian) somewhere in the Python build files?
(I ask first here to not create unnecessary lots of issues)