22 Dec
2011
22 Dec
'11
6:27 p.m.
I notice that 3.5.13 takes a long time to exit.
Normally I login from the command line and start X with the startx script. On my 2.3 GHz
dual core system with 4GB of RAM and SATA II hard drives, TDE takes about 7 to 8 seconds
to exit and more than once I have seen the system take up to 15 to 17 seconds to return to
the command line. I do not have sessions enabled, logoff confirmation is disabled, I
don't use eye candy, apps are already closed, etc.
My virtual machine takes about 7 to 8 seconds to exit to the command line.
On a 350 MHz PII system with 448 MB of RAM and ATA-2 IDE hard drives, exit time is about
16 seconds. I expect longer times but not that much. Yes, a PII is not a speed demon by
any modern standard, and such a system pushes the envelope of "old hardware,"
but if TDE is targeted for older hardware then the long exit time is not a good marketing
point, especially on a dual core system.
The dual core system uses the proprietary Nvidia drivers. The PII uses the tdfx driver and
a first generation AGP card.
For the record, 3.5.10 never was a speed demon at exiting either. I just expect more from
TDE. :)
There is an enhancement request to provide an option to disable displaying the
"Saving your settings" dialog box, but even if implemented, I doubt the dialog
box is responsible for the long exit delay.
What could be the cause? Is anybody else experiencing a long exit delay?
Darrell
22 Dec
22 Dec
8:18 p.m.
New subject: [trinity-devel] Slow TDE Exit Time
On 22 December 2011 13:27, Darrell Anderson <humanreadable(a)yahoo.com> wrote:
I notice that 3.5.13 takes a long time to exit.
This happens for me too, typically I get sick of it and just power off my
machine manually - bug report please!
I wonder what the underlying cause is.
Calvin Morrison
9:10 p.m.
New subject: [trinity-devel] Slow TDE Exit Time
I notice that 3.5.13 takes a long time to
exit.
This happens for me too, typically I get sick of
it and just power off my machine manually - bug report
please!
I wonder what the underlying cause is.
I'll file a bug report but I first I want to gather some information and comments.
Perhaps someobdy has a clue and I can add that information when I file the report. I'm
just sharing that my system exits too slow. I don't know whether the problem is TDE,
X, my OS or some combination thereof. Thus far I have one user confirmation. :)
I don't want to compare proverbial apples and oranges, but Xfce exits almost
immediately. Of course, window managers are even faster to exit. I realize there are some
settings to save.
Sometimes I wait for TDE to exit (KDE 3.5.10 too) and just press Ctrl-Alt-Backspace.
Generally, TDE always seems slower to exit than KDE. I use both. A second or two is one
thing but more than that and the desktop starts to remind me of that "other"
operating system. :)
Darrell
8:42 p.m.
New subject: [trinity-devel] Slow TDE Exit Time
I notice that 3.5.13 takes a long time to exit.
Normally I login from the command line and start X with the startx script.
On my 2.3 GHz dual core system with 4GB of RAM and SATA II hard drives,
TDE takes about 7 to 8 seconds to exit and more than once I have seen the
system take up to 15 to 17 seconds to return to the command line. I do not
have sessions enabled, logoff confirmation is disabled, I don't use eye
candy, apps are already closed, etc.
My virtual machine takes about 7 to 8 seconds to exit to the command line.
On a 350 MHz PII system with 448 MB of RAM and ATA-2 IDE hard drives, exit
time is about 16 seconds. I expect longer times but not that much. Yes, a
PII is not a speed demon by any modern standard, and such a system pushes
the envelope of "old hardware," but if TDE is targeted for older hardware
then the long exit time is not a good marketing point, especially on a
dual core system.
The dual core system uses the proprietary Nvidia drivers. The PII uses the
tdfx driver and a first generation AGP card.
For the record, 3.5.10 never was a speed demon at exiting either. I just
expect more from TDE. :)
There is an enhancement request to provide an option to disable displaying
the "Saving your settings" dialog box, but even if implemented, I doubt
the dialog box is responsible for the long exit delay.
What could be the cause? Is anybody else experiencing a long exit delay?
Darrell
The session manager shutdown is actually a 2 or 3 phase affair, and each
phase waits for apps (including kicker, kdesktop, things in your task
tray, etc.) to shut down normally before forcibly terminating them. There
are several opportunities for delays, and debugging this further will
require an instrumented build of tdebase that can profile the delay
intoduced by each phase.
This shouldn't be too hard to look at, please file an enhancement bug report.
Tim
9:33 p.m.
New subject: [trinity-devel] Slow TDE Exit Time
On Thu, 22 Dec 2011 14:42:22 -0600
"Timothy Pearson" <kb9vqf(a)pearsoncomputing.net> wrote:
I took a glance at the code and noticed some timeouts of:
-4 seconds for the legacy programs shutdown
-10 seconds for the protectionTimer which seems to manage libSM-aware
applications
If the code is thread-safe it is perhaps possible to encapsulate the
performLegacySessionSave() call in a pthread_create/pthread_join, or
without it we could give an option to disable the legacy session save
like KDE4 does.
Speaking of KDE4, I browsed the diff between the KDE 3.5.10 and KDE
4.7.4 ksmservers and found that they have similar shutdown logic so it
would be nice to send any improvement patch to the KDE team :)
(but regarding the graphical effects KDE4 seems to have much better and
MMX/SSE-optimized code)
I notice that
3.5.13 takes a long time to exit.
Normally I login from the command line and start X with the startx
script. On my 2.3 GHz dual core system with 4GB of RAM and SATA II
hard drives, TDE takes about 7 to 8 seconds to exit and more than
once I have seen the system take up to 15 to 17 seconds to return
to the command line. I do not have sessions enabled, logoff
confirmation is disabled, I don't use eye candy, apps are already
closed, etc.
My virtual machine takes about 7 to 8 seconds to exit to the
command line.
On a 350 MHz PII system with 448 MB of RAM and ATA-2 IDE hard
drives, exit time is about 16 seconds. I expect longer times but
not that much. Yes, a PII is not a speed demon by any modern
standard, and such a system pushes the envelope of "old hardware,"
but if TDE is targeted for older hardware then the long exit time
is not a good marketing point, especially on a dual core system.
The dual core system uses the proprietary Nvidia drivers. The PII
uses the tdfx driver and a first generation AGP card.
For the record, 3.5.10 never was a speed demon at exiting either. I
just expect more from TDE. :)
There is an enhancement request to provide an option to disable
displaying the "Saving your settings" dialog box, but even if
implemented, I doubt the dialog box is responsible for the long
exit delay.
What could be the cause? Is anybody else experiencing a long exit
delay?
Darrell
The session manager shutdown is actually a 2 or 3 phase affair, and
each phase waits for apps (including kicker, kdesktop, things in your
task tray, etc.) to shut down normally before forcibly terminating
them. There are several opportunities for delays, and debugging this
further will require an instrumented build of tdebase that can
profile the delay intoduced by each phase.
This shouldn't be too hard to look at, please file an enhancement bug
report.
Tim
---------------------------------------------------------------------
To unsubscribe, e-mail:
trinity-devel-unsubscribe(a)lists.pearsoncomputing.net For additional
commands, e-mail: trinity-devel-help(a)lists.pearsoncomputing.net Read
list messsages on the Web archive:
http://trinity-devel.pearsoncomputing.net/ Please remember not to
top-post:
http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
9:55 p.m.
New subject: [trinity-devel] Slow TDE Exit Time
If you are referring to the shutdown screen fading,
it
might be a good
idea to merge the MMX code into TDE.
Regarding the fadeaway, long ago I wrote a bug report to provide a KControl option to
disable the fadeaway. The fadeaway is too slow on older hardware. To me the fadeaway adds
no meaningful value but I'm not asking for a complete ripping. :) Lots of people like
that kind of eye candy, but we should have an option to disable the effect for those who
don't.
http://bugs.pearsoncomputing.net/show_bug.cgi?id=258
Darrell
10:06 p.m.
New subject: [trinity-devel] Slow TDE Exit Time
On Thu, 22 Dec 2011 13:55:06 -0800 (PST)
Darrell Anderson <humanreadable(a)yahoo.com> wrote:
FYI even your K6-II could take benefit of MMX optimizations.
If you are
referring to the shutdown screen fading, it
might be a good
idea to merge the MMX code into TDE.
Regarding the fadeaway, long ago I wrote a bug report to provide a
KControl option to disable the fadeaway. The fadeaway is too slow on
older hardware. To me the fadeaway adds no meaningful value but I'm
not asking for a complete ripping. :) Lots of people like that kind
of eye candy, but we should have an option to disable the effect for
those who don't.
http://bugs.pearsoncomputing.net/show_bug.cgi?id=258
Darrell
---------------------------------------------------------------------
To unsubscribe, e-mail:
trinity-devel-unsubscribe(a)lists.pearsoncomputing.net For additional
commands, e-mail: trinity-devel-help(a)lists.pearsoncomputing.net Read
list messsages on the Web archive:
http://trinity-devel.pearsoncomputing.net/ Please remember not to
top-post:
http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
10:15 p.m.
New subject: [trinity-devel] Slow TDE Exit Time
Regarding the
fadeaway, long ago I wrote a bug report
to provide a
KControl option to disable the fadeaway. The
fadeaway
is too slow on
older hardware. To me the fadeaway adds no
meaningful
value but I'm
not asking for a complete ripping. :) Lots of
people
like that kind
of eye candy, but we should have an option to
disable
the effect for
those who don't.
FYI even your K6-II
could take benefit of MMX
optimizations.
23 Dec
23 Dec
2:29 a.m.
New subject: [trinity-devel] Slow TDE Exit Time
On Thu, 22 Dec 2011 14:15:25 -0800 (PST)
Darrell Anderson <humanreadable(a)yahoo.com> wrote:
One of my older machines is a 400 MHz K6-III+ with 256 MB of RAM, but
you remember pretty close nonetheless. :) I confused with the K6-II I used when I
was a kid :)
Regarding the fadeaway, long ago I wrote a bug report
to provide a
KControl option to disable the fadeaway. The
fadeaway
is too slow on
older hardware. To me the fadeaway adds no
meaningful
value but I'm
not asking for a complete ripping. :) Lots of
people
like that kind
of eye candy, but we should have an option to
disable
the effect for
those who don't.
FYI even your K6-II
could take benefit of MMX
optimizations.
The other clunker here is a 350 MHz PII. Well, I have a 486 still
functioning, but nothing Linux related runs well on that box --- WFWG
3.11 with the Norton Desktop flies. :)
are you saying having tried a Linux
distribution 15 years younger than
your 486... with busybox/uclibc or Slackware 4.0 the performance would
probably have been better ;)
I use those machines as a performance yardstick of sorts for older
hardware. Most people today think a 1 GHz machine with 1 GB of RAM is
old. Not in this house. :)
Not in mine either, such a machine is just "a
little slow to use KDE4".
Especially with a Full HD panel and KWin effects automatically
activated ;)
Actually I still have a machine that I could use for KDE4/Trinity
optimisation (if I have the time to set up a cross-compiling
environment), it's not old (actually it's still in sale today) but has
a single-core non-x86 CPU and a very weak GPU which do a good job to
slaughter the Debian Squeeze's KDE4 performance.
Now, do you mean I need to recompile something to take advantage of
MMX optimizations or are you referring to something in TDE code that
should be tweaked with those optimizations?
It is not TDE code yet, but KDE4 code
that could be imported into TDE
(or alternatively I could implement my own MMX intrisics code...)
Darrell
---------------------------------------------------------------------
To unsubscribe, e-mail:
trinity-devel-unsubscribe(a)lists.pearsoncomputing.net For additional
commands, e-mail: trinity-devel-help(a)lists.pearsoncomputing.net Read
list messsages on the Web archive:
http://trinity-devel.pearsoncomputing.net/ Please remember not to
top-post:
http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
3:54 a.m.
New subject: [trinity-devel] Slow TDE Exit Time
On Thu, 22 Dec 2011 13:55:06 -0800 (PST)
Darrell Anderson <humanreadable(a)yahoo.com> wrote:
File
kdebase/ksmserver/shutdowndlg.cpp:113:
If you are
referring to the shutdown screen fading, it
might be a good
idea to merge the MMX code into TDE.
Regarding the fadeaway, long ago I wrote a bug report to provide a
KControl option to disable the fadeaway. The fadeaway is too slow on
older hardware. To me the fadeaway adds no meaningful value but I'm
not asking for a complete ripping. :) Lots of people like that kind
of eye candy, but we should have an option to disable the effect for
those who don't.
http://bugs.pearsoncomputing.net/show_bug.cgi?id=258 if (KConfigGroup(KGlobal::config(),
"Logout").readBoolEntry("doFancyLogout", true))
This seems to
refer to a non-existing option; perhaps it existed in the
Kubuntu panel...
Darrell
---------------------------------------------------------------------
To unsubscribe, e-mail:
trinity-devel-unsubscribe(a)lists.pearsoncomputing.net For additional
commands, e-mail: trinity-devel-help(a)lists.pearsoncomputing.net Read
list messsages on the Web archive:
http://trinity-devel.pearsoncomputing.net/ Please remember not to
top-post:
http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
5:25 a.m.
New subject: [trinity-devel] Slow TDE Exit Time
File
kdebase/ksmserver/shutdowndlg.cpp:113:
Hey! Those settings work! :)
Hmm. My foggy memory seems to recall a long time ago that Tim said feature controls were
available in the config file but there was no KControl interface. :)
I took a guess the settings belong in ksmserverrc (how would I actually learn that from
the code?). This is what is needed:
[Logout]
doFancyLogout=false
doFancyLogoutAdditionalDarkness=0.6
doFancyLogoutFadeTime=4000
doFancyLogoutFadeBackTime=1000
doUbuntuLogout=false
Setting doFancyLogout to false does indeed stop the fadeaway effect.
The doFancyLogoutAdditionalDarkness seems to have an upper limit of 1.0. Beyond that and
my screen went goofy. The lower limit seems to be 0.0. The entire screen goes black and
only a remnant of the kicker panel is still seen.
Playing with doFancyLogoutFadeTime and doFancyLogoutFadeBackTime changes how fast the
fadeaway appears and disappears. I don't know the lower and upper limits. I imagine
zero is the lower limit as the numbers represent milliseconds.
So seems these settings can be inserted manually. Actually, only doFancyLogout is needed
to enable or disable the effect. The other settings could be ignored and the code will use
the defaults.
If somebody was to create an interface then I'd think something like this in KDE
Components/Session Manager, General section:
All of the following are disabled/ghosted when "Confirm logout" is unchecked.
When "Confirm logout" is enabled then the following widget is
enabled/unghosted.
* A radio button: Enable fancy gray fadeaway
When that radio button is enabled then the following become enabled/unghosted:
* A slider control from zero to 1.0 for darkness
* A slider control from zero to ?? milliseconds for fade time
* A slider control from zero to ?? milliseconds for restore time
* If the system is running the Ubuntu OS, then a check box appears, but only if the OS is
Ubuntu.
I'll add this information to the bug report!
Darrell
if (KConfigGroup(KGlobal::config(),
"Logout").readBoolEntry("doFancyLogout", true))
This seems to refer to a non-existing option; perhaps it
existed in the
Kubuntu panel...
5:40 a.m.
New subject: [trinity-devel] Slow TDE Exit Time
If somebody was to create an interface then I'd
think
something like this in KDE Components/Session Manager,
General section:
All of the following are disabled/ghosted when "Confirm
logout" is unchecked. When "Confirm logout" is enabled then
the following widget is enabled/unghosted.
* A radio button: Enable fancy gray fadeaway
When that radio button is enabled then the following become
enabled/unghosted:
* A slider control from zero to 1.0 for darkness
* A slider control from zero to ?? milliseconds for fade
time
* A slider control from zero to ?? milliseconds for restore
time
* If the system is running the Ubuntu OS, then a check box
appears, but only if the OS is Ubuntu.
Oops. I meant check box, not radio button. :)
Darrell
22 Dec
22 Dec
10:09 p.m.
New subject: [trinity-devel] Slow TDE Exit Time
This
shouldn't be too hard to look at, please file an
enhancement bug report.
I took a glance at the code and noticed some timeouts
of:
-4 seconds for the legacy programs shutdown
-10 seconds for the protectionTimer which seems to manage
libSM-aware
applications
If the code is thread-safe it is perhaps possible to
encapsulate the
performLegacySessionSave() call in a
pthread_create/pthread_join, or
without it we could give an option to disable the legacy
session save
like KDE4 does.
Hey hey, now we're talking. :) Perhaps those timeouts explain why occasionally I see
longer exit times.
Darrell
10:29 p.m.
New subject: [trinity-devel] Slow TDE Exit Time
The session manager shutdown is actually a 2 or 3
phase
affair, and each
phase waits for apps (including kicker, kdesktop, things in
your task
tray, etc.) to shut down normally before forcibly
terminating them. There
are several opportunities for delays, and debugging this
further will
require an instrumented build of tdebase that can profile
the delay
introduced by each phase.
This shouldn't be too hard to look at, please file an
enhancement bug report.
http://bugs.pearsoncomputing.net/show_bug.cgi?id=760
We can file additional information when we start troubleshooting, but as a habit I close
all apps before exiting. KAlarm, KMix, KwikDisk, Klippy, and Akregator are in my system
tray, which must be closed when exiting. I run with one instance of Konqueror preloaded in
memory. Most of the kded daemons are running too.
I'm willing to collect data if anybody offers ideas.
Darrell
24 Dec
24 Dec
5:32 a.m.
New subject: [trinity-devel] Slow TDE Exit Time
This
shouldn't be too hard to look at, please file an
enhancement bug report.
http://bugs.pearsoncomputing.net/show_bug.cgi?id=760
We can file additional information when we start
troubleshooting, but as a habit I close all apps before
exiting. KAlarm, KMix, KwikDisk, Klippy, and Akregator are
in my system tray, which must be closed when exiting. I run
with one instance of Konqueror preloaded in memory. Most of
the kded daemons are running too.
4780
days inactive
4782
days old
15 comments
4 participants
participants (4)
-
/dev/ammo42 -
Calvin Morrison -
Darrell Anderson -
Timothy Pearson