Thomas,

to correct the statement of another poster, I can tell you, that all data design in the core is made by developers with great insight and experience, especially the new user profiles, which needed to combine security, flexibility, maintainability and speed - aims that are struggling with each other.

Though normalized tables are usually preferable, there are issues, that might recommend another solution - due to speed (using redundant data) or flexibility (using a serialized storage format as UserDefinedTable and Profile Editor). And as far as I see, most of the overhead in DotNetNuke comes from the need, to fullfil many different needs, providing more and more options, that needs to be handled with additonal code - but as far as I read demands in these forums, most of these options are due to demand of the users, so they cannot be removed. Another source of additional code is code design with clearly separated layers, abstraction levels and provider integration. this leads into additional calls, but allows easier testing and encreases code quality.

As a conclusion: If you want a flexible, secure system for multi purposes, you well need to accept some performance loosings. If your main goal is performance, write an application, that is designed for a single special purposes.

My 2 cents.

Speaking of integrated features that you can't turn off.  The biggest hit on performance that I have been able to track down is Localization.
Every time a language resouce file is loaded it is put into and XMLDocument (slow), then converted to a hashtable and cached.
One moderate caching performance setting, it will stay in cache for 1 hour, 2 hours for heavy caching.

Sebastian won't like this much, but some of us would rather choose to just turn of localization instead of taking that performance hit, especially if we are running on an Intranet.  Unfortunately that is next to impossible, since a lot of the core uses the language resource files by default.

I do have an idea brewing that I think will get us the performance back from Localization, and keeping the flexability that it has now by allowing language packs to be built and uploaded seperately.

Basically, what we need to do is build a process that will collect all language files for a language and put them into one static file, then load it into cache with an XMLDatareader(fast) in a way that is optimized for memory and faster lookup. 

Then again, you could get the PageBlaster and get a huge performance boost right now. :~)