"David LeBlanc" <whisper at oz.net> writes: > A few things come to mind: > > What's the cost of mapping the world (all those entry points) at startup? > > You have to rebuild all of the main dll just to do something to one > component. To me, that's maybe the biggest single issue. Hm. How often do you hack the C code of the extension modules included with Python? > Are app users/programmers going to have a bloat perception? How many of them > really understand that a dll is mapped and not loaded at startup? > > IMO, it contradicts the unix way of smaller, compartmentalized is better. > It's not unix we're talking about, but it still makes sense to me, whatever > the OS. Maybe unix solves all this, but on Windows it's called DLL Hell. > On the plus side, it does make some debugging easier if you're working on > extension dlls: fewer sources to have to point Vis Studio at. That's never been a problem for me. It always finds the sources itself, at least for extensions built with distutils (because distutils in debug builds passes absolute pathnames to the compiler). > On a related side note: has anyone done any investigation to determine which > few percentage of the extensions account for 99% of the dll loads? Maybe > there's no such pattern, but experience suggests there probably is and that > subset might be a better candidate than the whole world. That might be. Thomas
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4