hello, thanks for all replies here is what i got so far:
The main problem is that Drupal 5 and earlier by design loaded ALL code on every page load. In Drupal 6 we introduced split include files for page callbacks, so most of those "foo.admin.inc" and "foo.pages.inc" files are not, in fact, loaded on every page request but only when needed. There are similar techniques that individual modules can implement if necessary for their own code, and some of the larger ones like Views and CCK do, but there's no central mechanism for it.
All my modules are split to many .inc files loaded only when needed. But drupal still includes all 67 .module files.
Hooks aren't the issue per se, although it is true that there's a cost to checking 50 modules for a hook.
Both of those are seeing major improvements in D7, but they're not anywhere near production ready yet.
An opcode cache will help immensely for the first problem, as that's the main thing it solves. Proper tuning of the cache (you can set it to not even stat the disk) will help, too. I tried APC ... load times are faster but not enough :D (according to APC stat, there is enough cache memory and other settings seem OK too) I tried turn off file modification chceking ... not much improvement and APC include_once hack ... with that option set, drupal refused to start ...
Beyond that, depends on your modules. You may find some you do not, in fact, need. Actually, problem is that i need all of them ;). There are few core modules. All other modules are custom and are used daily. (Most of them are just form and "do-something-with-external-system" when submitted.)
Others you could look into improving by implementing some sort of lazy- loading mechanism like Views does. (I believe Views' mechanism is being split off to the ctools module, now in alpha.) You'd have to work with the maintainers for those. Some modules wouldn't really support it, sadly. For external systems, definitely look into proper caching, even if you think it's fast. You can also look into tuning the block cache, or using memcache instead of the default db caching, perhaps, but that's probably overkill if you are just running an intranet server.
Problem with caching is that all modules use "live" data, or are generating unique reports. I can't cache anything.
Anyway, that's just general purpose advise. And, um, no, don't hack core. Really. You will regret it. Maybe not today, maybe not tomorrow, but soon, and for the rest of your life.
I know that hacking core is the last resort and is generally bad idea :D. ------------------------------------------------------------------------------------------------- And there is another thing that can help: I need that only one module (used most and in critical process) should be as fast as possible. So i tried little trick: There is function list_modules in core returning list of modules witch are then loaded. As i only need one module to be as fast as possible and i don't really care about others. In the list_modules function i check witch module is being loaded (something like if $q is like /is/*). If it's my module - instead of full module list, I return manually created reduced module list. Result is that only 17 modules out of 67 are loaded ... but the problem is that it didn't helped much :( - maybe the bottleneck is somewhere else and not in drupal module load system. I'm going to try few more tricks :) and I write back when I find out something interesting.