[kde-linux] Re: help, kde 4.6 desktop very very slow

[Duncan]

Juan Pablo Romero Méndez posted on Fri, 06 May 2011 21:17:43 -0500 as
excerpted:

> Hello,
> 
> I've just upgraded to opensuse 11.4, which came with kde 4.6
> 
> The problem is that the keyboard input is so slow that renders the
> system virtually unusable.
> 
> I've been monitoring the system with top but can't find something
> obvious.
> 
> The weird thing is that on another account I made just to test, kde runs
> fine. It is something with my account that kde doesn't like.
> Perhaps its size (300G), perhaps some config file from another version.
> 
> Also, the linux console works fine.
> 
> What do you guys think?

You include some good info, but there's some potentially critical info 
missing, too.

1)  You say you just upgraded to OpenSuSE 11.4, which comes with KDE 4.6, 
but you don't mention /which/ 4.6.  There's now 4.6.0, 4.6.1, 4.6.2, and 
the /just/ released 4.6.3.

2)  What did you upgrade /from/, both distribution-wise and presuming you 
ran kde on it, what version of kde?

Just upgrading from an old kde-3.5.x installation could yield far 
different results than just upgrading from, say 4.3 or 4.4, which could be 
rather different than upgrading from 4.5.x, which is different again from 
upgrading from last month's 4.6.2 to the just released 4.6.3 (the upgrade 
I just did here, Gentoo, FWIW).

3) *VERY* good thinking trying a test user account, and putting the 
results in your post! =:^)  That it doesn't occur there does indeed 
indicate, as you suggested, that it's a user config issue.  The problem is 
now finding out what/where.  That's where the above info may come in 
handy, since upgrading from 3.5.x is really quite different indeed from 
upgrading from 4.5.5, and if an upgrade between 4.6 versions is causing 
issues, it's quite interesting as those should be bug-fix-only upgrades 
(not that the 4.6 series has been as smooth as in theory bug-fix-only 
upgrades should be, there's unfortunately been some notable regressions).

Meanwhile, continuing from the new-user test, do you know what bisecting a 
problem is?  Since we know it's in your user config, that's how I'd 
approach it.

Briefly, the idea behind bisecting is that once you have a known problem 
space (in this case, your user config), one can iteratively narrow the 
problem down to successively smaller parts of that problem space, at each 
iteration figuring out which half of the remaining problem space it's in, 
until one finds the problem.

To shortcut the process by a couple iterations, nearly all kde's config is 
found in $KDEHOME, normally ~/.kde, or possibly ~/.kde4, depending on 
distribution.  So that's the config directory we'll assume it's in, and 
the first step is confirming that.  Without kde running (so from a CLI 
login or from gnome or whatever), rename your problem user's ~/.kde (or 
kde4) directory to something like .kde.bak.

Now start kde as your problem user.  Is the problem gone?  If so, we've 
confirmed that the problem is in $KDEHOME.

Assuming it is, the next step is to split that in half.  Again taking a 
shortcut, nearly all kde settings are in the $KDEHOME/share, in one of two 
subdirs, config or apps.  So again with kde not running, delete the stub 
$KDEHOME our first test created and copy back all of the dir from the 
backup BUT $KDEHOME/share/config.

Rerun the test.  If the problem is still gone, we know the problem file is 
one of those in config.  If the problem is there again, we can assume 
config is fine and that the problem is in one of the apps subdirs, instead.
Delete the stub config dir created by the test.

If the problem was in config (didn't appear in the test above), copy half 
the files from the config dir in your backup to the operating location, 
and retest.

If the problem was NOT in config (it did appear in the test above), go 
ahead and copy all your config files back from the backup, and delete the 
apps subdir instead.  Retest to confirm that it's in apps.

Repeat until you've isolated the problem file.  At this point, you have a 
choice.  You can either stop, delete that file and reconfigure anything 
that its settings controlled as necessary, OR switch to a text editor 
instead of the file manager for testing, and continue, first with sections 
within the file until you figure out which section it's in, then with 
individual lines in that section.  FWIW, I like to figure out exactly what 
has caused me all this hassle, so generally do continue down to the 
individual line level.  But people with less patience or less 
customization than I have may be fine stopping at the file level, or even 
higher, if they decide the hassle of testing further is greater than the 
hassle of reconfiguring the customizations remaining in whatever number of 
files will be deleted.

For the type of problem you've indicated, a bisect, while being somewhat 
boring and requiring quite some patience, tends to be very effective, 
resolving the problem nearly every time.  Unfortunately it doesn't work so 
well on problems that aren't easily replicated, thus making testing each 
bisect level far more difficult as you never know for sure whether you're 
on the good half or if the problem simply hasn't triggered yet.  
Similarly, if there's two separate causes for the problem, bisecting 
doesn't work well if at all, because it's difficult to find both of them 
at once.  So bisecting certainly does have its limits, but for easily 
replicated problems in a known to be limited problem space and likely 
having only one cause, as is your case, it tends to work pretty well... as 
long as you have enough patience to carry thru with the repetitive testing.

Good luck! =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman