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.