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

Sat May 7 19:41:59 UTC 2011

Thanks for your response Duncan,

The upgrade is not an issue anymore because in a moment of desperation
I formated the root partition and reinstalled  opensuse.  The version
of kde shipped with it is 4.6.0.

Also I tried deleting the ~/.kde4 folder and nothing happened.

Deleting ~/.local caused something interesting to occur:   the first
few seconds after loading the desktop, the system was very responsive
(I thought the issue was resolved), but after some more seconds the
problem begun again.

Examining a newly created ~/.local, the only interesting thing I see
is akonadi's folder in ~/.local/share/akonadi.  Within it there are
several files and folders that appears to belong to mysql.

Regards,

  Juan Pablo

2011/5/6 Duncan <1i5t5.duncan at cox.net>:
> 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
>
> ___________________________________________________
> This message is from the kde-linux mailing list.
> Account management:  https://mail.kde.org/mailman/listinfo/kde-linux.
> Archives: http://lists.kde.org/.
> More info: http://www.kde.org/faq.html.