Sitealizer in trunk a bad idea? Bloat and stability issues

Okay, maybe I’m completely off base here, but this seemed like the
best place to check. Sorry if I step on any toes. Something in a
recent upgrade seems to have made my typo install a total memory hog -
like way more than it was before, even. I did an update where the
addition of sitealizer was the most obvious change, and then
everything went tits up. I’m just picking on sitealizer, because it’s
an obvious target, but I have zero firm evidence that is it, and I
might be completely wrong.

I’m trying to get my blog back up after the subsequent downgrade, and
then I’ll see if it runs smoother - like less than a couple hundred
megs across 4 worker processes it is immediately consuming upon

I assume sitealizer runs some around filters on each request, or
something similar? Does it do so on admin requests too, because my
live preview went super extra wonky (even if sitealizer isn’t the main
cause of my problem, having it run on the live preview would be bad,
obviously). Does this not invalidate some of the benefits of the
caching? I know trunk isn’t expected to be stable, but maybe sort of
thing should go in experimental?

I understand the wish to add every possible feature, but I figure most
bloggers capable of running typo have google analytics, feedburner,
and their own server side analysis tools already and typo doesn’t
exactly have a reputation as the sveltest platform. In fact issues
keeping typo running on a shared host seem to be one the biggest
common Rails
deployment problems. Hmm, I wonder if a default base install with a
lot of the “optionals” coughcruftcough not on by default would help


So it seems I am running a fatter and more sluggish than it has in
recent memory, even with sitealizer axed. This whole thing makes me
wonder, how hard would it be to make a minimal branch, that instead of
having all the filters, sidebars, and extra processing steps on by
default, they have to be added or enabled.

With all of this directly added in the main repository as they are
(instead of accessed by externals, maybe?), even if you go through the
pain of cleaning out your vendor and plugin folder, to pare down what
you aren’t using, you’re doomed if you ever want to run svn update.