By default, Bugzilla does not search the list of RESOLVED bugs.
You can force it to do so by putting the upper-case word ALL in front of your search query, e.g.: ALL tdelibs
We recommend searching for bugs this way, as you may discover that your bug has already been resolved and fixed in a later release.
Bug 1801 - kmix takes a long time to load on older hardware
Summary: kmix takes a long time to load on older hardware
Status: RESOLVED FIXED
Alias: None
Product: TDE
Classification: Unclassified
Component: tdemultimedia (show other bugs)
Version: R14.0.x [Trinity]
Hardware: Other Linux
: P5 normal
Assignee: Timothy Pearson
URL:
Depends on:
Blocks:
 
Reported: 2013-12-30 11:20 CST by Darrell
Modified: 2018-08-01 04:57 CDT (History)
4 users (show)

See Also:
Compiler Version:
TDE Version String:
Application Version:
Application Name:

Attachments
PI callgrind output (525.46 KB, application/octet-stream)
2013-12-30 11:20 CST, Darrell 		Details
PI strace output (45.94 KB, text/plain)
2013-12-30 11:20 CST, Darrell 		Details
PII callgrind output (525.58 KB, application/octet-stream)
2013-12-30 11:21 CST, Darrell 		Details
PII strace output (36.75 KB, text/plain)
2013-12-30 11:21 CST, Darrell 		Details
Thinkpad T400 dual core laptop callgrind output (for reference) (525.91 KB, application/octet-stream)
2013-12-30 11:22 CST, Darrell 		Details
Thinkpad T400 dual core laptop strace output (for reference) (47.21 KB, text/plain)
2013-12-30 11:22 CST, Darrell 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Darrell 2013-12-30 11:20:24 CST 
Created attachment 1801 [details]
PI callgrind output

I have a PI and a PII I use for corner case testing. Despite being bottom of the barrle hardware, both have proven useful with testing Trinity. During such testing I notice kmix loads very slowly on both systems.

I'm attaching some valgrind and strace outputs.
Comment 1 Darrell 2013-12-30 11:20:50 CST 
Created attachment 1802 [details]
PI strace output
Comment 2 Darrell 2013-12-30 11:21:13 CST 
Created attachment 1803 [details]
PII callgrind output
Comment 3 Darrell 2013-12-30 11:21:30 CST 
Created attachment 1804 [details]
PII strace output
Comment 4 Darrell 2013-12-30 11:22:20 CST 
Created attachment 1805 [details]
Thinkpad T400 dual core laptop callgrind output (for reference)
Comment 5 Darrell 2013-12-30 11:22:43 CST 
Created attachment 1806 [details]
Thinkpad T400 dual core laptop strace output (for reference)
Comment 6 Timothy Pearson 2014-07-15 15:59:28 CDT 
I'm thinking this might have been fixed in GIT hash ae6bdb2 when I repaired insanely large icons being loaded into memory on startup.  Can you confirm?

Thanks!
Comment 7 Darrell 2014-07-15 16:16:13 CDT 
I won't be able to test this for several days. The PI and PII systems run Slackware 14.0. My main office system runs 14.1, of which recently I built new Trinity packages. I have to build Trinity for 14.0 before I can test the PI and PII. I don't try to keep the PI and PII current. I only do so when they serve my needs for special testing. Updating the systems will take a few days.

I do not find a commit ae6bdb2 in the commit web page. What module was the commit?
Comment 8 Timothy Pearson 2014-07-15 17:02:15 CDT 
(In reply to Darrell from comment #7)
> I won't be able to test this for several days. The PI and PII systems run
> Slackware 14.0. My main office system runs 14.1, of which recently I built
> new Trinity packages. I have to build Trinity for 14.0 before I can test the
> PI and PII. I don't try to keep the PI and PII current. I only do so when
> they serve my needs for special testing. Updating the systems will take a
> few days.
> 
> I do not find a commit ae6bdb2 in the commit web page. What module was the
> commit?

Wow, I have no idea where that hash came from on my clipboard!  Sorry about that.

The correct hash is 1742070b; module tdemultimedia.

Tim
Comment 9 Darrell 2014-07-16 17:47:44 CDT 
After these many months after filing the bug report, I don't know that I am testing with the same parameters or even what those original parameters might have been. I lack any reference times from the original observations. I presume I filed the bug report because the delay with seeing the kmix icon was a long time. The kmix icon now appears several seconds after the klipper icon, which probably is normal considering how slow the machines are, but as I lack numbers or memory of the original problem I can't say with certainty whether the problem is resolved or whether the problem was resolved by the aforementioned patches or some other patch.

Testing with the PI and PII is painfully slow. I don't think anything from a modern distro will run with the speed of the software used in the days the systems were manufactured, or even close to that speed. Everything on these systems is slow.

I don't know what the recent patches are all about. I never saw any problems on my main systems, albeit all of my main systems are dual cores with modern GPUs.

Nobody in their right mind would use a PI or PII with a modern distro as a desktop. Might as well close this report as WONTFIX.
Comment 10 Michele Calgaro 2018-08-01 04:57:49 CDT 
As suggested in comments, this bug may have been fixed by other commits and Darrell thinks it is now working normally.