Take a look at hypeThemeX, it uses a higher version of jQuery with jQuery Migrate (in silent mode), so Elgg's JS libs run without issues.

As a temporary solution you can try jquery migrate plugin which supports the deprecated APIs.

https://github.com/jquery/jquery-migrate/

Already raised a ticket for this @ https://github.com/Elgg/Elgg/issues/6679

Here's the code that works for me using the latest jQuery CDN, even the dropdown works now.

// Unregister Elgg's old jQuery
elgg_unregister_js('jquery');
// Always register the latest jQuery version without you having to do anything
elgg_register_js('jquery-CDN','http://code.jquery.com/jquery-latest.min.js');
// Load our latest jQuery
elgg_load_js('jquery-CDN');

// jQuery migrate is necessary since Elgg uses old jQuery code
elgg_register_js('jquery-migrate-CDN','https://code.jquery.com/jquery-migrate-1.2.1.min.js');
// Load this important library
elgg_load_js('jquery-migrate-CDN');

// Unregister Elgg's Jquery UI
elgg_unregister_js('jquery-ui');
// Register CDN jQuery UI
elgg_register_js('jquery-ui-cdn', 'http://ajax.googleapis.com/ajax/libs/jqueryui/1/jquery-ui.min.js');
// Load CDN jQuery UI
elgg_load_js('jquery-ui-cdn');

as far as overall 'caching' goes - an interesting maybe (but hypothetical solution b/c php needs to be compiled with shmop enabled) - would be to use shmop for a lot of the elgg's shared data; most servers, (@cheap hosting!) will not have shmop. or maybe even using gearman (but definite overkill!) to delegate/farm-out/manage elgg's 'system' tasks. i wonder.. what some experimenting might reveal.. point #7 needs someone to volunteer time to research which code modules are needed when and where, what circumstances...? so that perhaps we can build some kind of dependency table for all modules, includes and so on - for optimized code loading.

Some good suggestions & data here. Could you please post a 2nd screenshot after sorting the functions by time?

Function calls are relatively cheap/fast. I would guess that total time spent on elgg_get_viewtype() is very little.

Further optimization of elgg_get_entities is coming soon!

We're moving rarely-need code into components that are lazy-loaded if/when needed. The lib files @TeamWegalli says you can do without are excellent candidates for this refactorization. For BC we at least need stub functions that lazy-load the component to do the work.

Registration like action/page/hook handlers can't be cached without setting rules for when these are registered and requirements that they be the same on every request. I tend to think the opposite: the plugin API should announce what kind of request it is (which handler is executing) and let plugins register only what they'll need for the request.

There's also some low hanging fruit like http://trac.elgg.org/ticket/4495

I'd like to lazy-load the login form that appears when you click "Log in". It'd also be better to make that form an iframe so browser auto-complete would work everywhere.

Good remarks and good comments. I think most problems and ideas were mentioned already. I have one more to add.

For some time we're investigating how we could improve performance by restructurizing plugin's architecture. I think it would be a good solution to rewrite all code that is in start.php to a plugin class, which would inherit from ElggPlugin. This class could take care of registering libraries when they're needed, loading page handlers, actions etc. This would have a few advantages, some of them being:

• we have an option to lazy load some code (eg. action registration, handlers etc., but also register need for core libraries)
• it's easy to find out what you can do with plugin by looking at a parent class
• it's possible to easily overwrite parts of a plugins with inheritance
• it streamlines how this code looks and works

Parallel thread: http://groups.google.com/group/elgg-development/browse_thread/thread/4cc2e6cfd728b3e6