I'm using the latest GIT.
I haven't done any deep digging but there is no doubt that Konqueror is opening much slower than I am accustomed. Any request to open Konqueror takes two or more seconds. This is a dual core system with 8GB RAM and SATA II disks.
I have not seen this problem before. Only recently.
I have an instance preloaded and always have had that option enabled, but what I see indicates this is not happening. Could there have been a patch in the past few weeks that is affecting preloading?
I checked Konqueror in a virtual machine using a GIT package set that hasn't been updated in a couple of months. There, Konqueror opened right away, thereby confirming my observations in my normal system.
A fresh profile makes no difference.
Anybody else noticing this?
Darrell
I'm using the latest GIT.
I haven't done any deep digging but there is no doubt that Konqueror is opening much slower than I am accustomed. Any request to open Konqueror takes two or more seconds. This is a dual core system with 8GB RAM and SATA II disks.
I have not seen this problem before. Only recently.
I have an instance preloaded and always have had that option enabled, but what I see indicates this is not happening. Could there have been a patch in the past few weeks that is affecting preloading?
I checked Konqueror in a virtual machine using a GIT package set that hasn't been updated in a couple of months. There, Konqueror opened right away, thereby confirming my observations in my normal system.
A fresh profile makes no difference.
Anybody else noticing this?
Um, KMail too.
I reverted to my package set from GIT short version 8443 Oct. 30 and both Konqueror and KMail again open quickly.
Tim, would the recent style engine patches cause apps to open slowly?
Darrell
I'm using the latest GIT.
I haven't done any deep digging but there is no doubt that Konqueror is opening much slower than I am accustomed. Any request to open Konqueror takes two or more seconds. This is a dual core system with 8GB RAM and SATA II disks.
I have not seen this problem before. Only recently.
I have an instance preloaded and always have had that option enabled, but what I see indicates this is not happening. Could there have been a patch in the past few weeks that is affecting preloading?
I checked Konqueror in a virtual machine using a GIT package set that hasn't been updated in a couple of months. There, Konqueror opened right away, thereby confirming my observations in my normal system.
A fresh profile makes no difference.
Anybody else noticing this?
Um, KMail too.
I reverted to my package set from GIT short version 8443 Oct. 30 and both Konqueror and KMail again open quickly.
Tim, would the recent style engine patches cause apps to open slowly?
Darrell
It is possible, though that would definitely be considered a bug! I will run konqueror through callgrind and see if anything pops out.
Tim
I'm using the latest GIT.
I haven't done any deep digging but there is no doubt that Konqueror is opening much slower than I am accustomed. Any request to open Konqueror takes two or more seconds. This is a dual core system with 8GB RAM and SATA II disks.
I have not seen this problem before. Only recently.
I have an instance preloaded and always have had that option enabled, but what I see indicates this is not happening. Could there have been a patch in the past few weeks that is affecting preloading?
I checked Konqueror in a virtual machine using a GIT package set that hasn't been updated in a couple of months. There, Konqueror opened right away, thereby confirming my observations in my normal system.
A fresh profile makes no difference.
Anybody else noticing this?
Um, KMail too.
I reverted to my package set from GIT short version 8443 Oct. 30 and both Konqueror and KMail again open quickly.
Tim, would the recent style engine patches cause apps to open slowly?
Darrell
It is possible, though that would definitely be considered a bug! I will run konqueror through callgrind and see if anything pops out.
Tim
The only thing that sort of stands out in valgrind is a number of calls to windowState(), presumably from line 620 of tqt3/src/styles/qcommonstyle.cpp
Can you try commenting out that line to see if it resolves the slow startup issue? You only need to recompile/reinstall TQt3 itself to test, then log out/log back in to TDE.
Tim
The only thing that sort of stands out in valgrind is a number of calls to windowState(), presumably from line 620 of tqt3/src/styles/qcommonstyle.cpp
Can you try commenting out that line to see if it resolves the slow startup issue? You only need to recompile/reinstall TQt3 itself to test, then log out/log back in to TDE.
Commenting out lines 619-621 makes a difference, but I need to revert to my Oct. 30 package set and run some as-best-I-can stopwatch tests. The reason is the patch helps but my intuition tells me the apps are not opening as fast as the Oct. 30 package set.
I notice the commented lines are from commits 37a8b8a9 and 79dfe5ba of Nov. 4, which at least fits the time frame in question. From my perspective then, looks like some of the style engine work is indeed affecting app launch times. Hopefully they can be resolved. :)
Swapping package sets takes a while. :) Eventually I'll present some crude stopwatch benchmarks. :)
Darrell
The only thing that sort of stands out in valgrind is a number of calls to windowState(), presumably from line 620 of tqt3/src/styles/qcommonstyle.cpp
Can you try commenting out that line to see if it resolves the slow startup issue? You only need to recompile/reinstall TQt3 itself to test, then log out/log back in to TDE.
Commenting out lines 619-621 makes a difference, but I need to revert to my Oct. 30 package set and run some as-best-I-can stopwatch tests. The reason is the patch helps but my intuition tells me the apps are not opening as fast as the Oct. 30 package set.
I notice the commented lines are from commits 37a8b8a9 and 79dfe5ba of Nov. 4, which at least fits the time frame in question. From my perspective then, looks like some of the style engine work is indeed affecting app launch times. Hopefully they can be resolved. :)
Swapping package sets takes a while. :) Eventually I'll present some crude stopwatch benchmarks. :)
Here are my best-I-can stopwatch benchmarks. All times in seconds. Each time I flushed the ksycoca cache and restarted Trinity.
GIT short version 8443, Oct. 30
kate: 1.54, 1.29, 1.35; avg.: 1.39 konqueror: 1.47, 1.61, 1.57; avg.: 1.55 kmail: 2.09, 1.96, 1.97; avg.: 2.01
GIT short version 8665, Nov. 10, patched
kate: 1.68, 1.89, 1.73; avg.: 1.77 konqueror: 3.20, 2.81, 2.52; avg.: 2.84 kmail: 3.37, 3.47, 3.29; avg.: 3.38
GIT short version 8665, Nov. 10, unpatched
kate: 1.97, 1.94, 1.80; avg.: 1.90 konqueror: 3.60, 2.83, 3.21; avg.: 3.21 kmail: 3.72, 3.39, 3.47; avg.: 3.53
In the 8665 build there is a nominal improvement with the patch but either way, there is noticeable difference between the package sets. Enough that all users will notice. I'm running on a decent machine but I suspect users with less older hardware will notice more. :)
Darrell
The only thing that sort of stands out in valgrind is a number of
calls to
windowState(), presumably from line 620 of
tqt3/src/styles/qcommonstyle.cpp
Can you try commenting out that line to see if it resolves the slow startup issue? You only need to recompile/reinstall TQt3 itself to
test,
then log out/log back in to TDE.
Commenting out lines 619-621 makes a difference, but I need to revert to my Oct. 30 package set and run some as-best-I-can stopwatch tests. The reason is the patch helps but my intuition tells me the apps are not opening as fast as the Oct. 30 package set.
I notice the commented lines are from commits 37a8b8a9 and 79dfe5ba of Nov. 4, which at least fits the time frame in question. From my perspective then, looks like some of the style engine work is indeed affecting app launch times. Hopefully they can be resolved. :)
Swapping package sets takes a while. :) Eventually I'll present some crude stopwatch benchmarks. :)
Here are my best-I-can stopwatch benchmarks. All times in seconds. Each time I flushed the ksycoca cache and restarted Trinity.
GIT short version 8443, Oct. 30
kate: 1.54, 1.29, 1.35; avg.: 1.39 konqueror: 1.47, 1.61, 1.57; avg.: 1.55 kmail: 2.09, 1.96, 1.97; avg.: 2.01
GIT short version 8665, Nov. 10, patched
kate: 1.68, 1.89, 1.73; avg.: 1.77 konqueror: 3.20, 2.81, 2.52; avg.: 2.84 kmail: 3.37, 3.47, 3.29; avg.: 3.38
GIT short version 8665, Nov. 10, unpatched
kate: 1.97, 1.94, 1.80; avg.: 1.90 konqueror: 3.60, 2.83, 3.21; avg.: 3.21 kmail: 3.72, 3.39, 3.47; avg.: 3.53
In the 8665 build there is a nominal improvement with the patch but either way, there is noticeable difference between the package sets. Enough that all users will notice. I'm running on a decent machine but I suspect users with less older hardware will notice more. :)
Darrell
Where are you getting the GIT short versions from?
What TDE widget style are you using?
And finally, can you/would you be willing to bisect the GIT tree to find the offending commit?
Thanks!
Tim
The only thing that sort of stands out in valgrind is a number of
calls to
windowState(), presumably from line 620 of
tqt3/src/styles/qcommonstyle.cpp
Can you try commenting out that line to see if it resolves the slow startup issue? You only need to recompile/reinstall TQt3 itself to
test,
then log out/log back in to TDE.
Commenting out lines 619-621 makes a difference, but I need to revert to my Oct. 30 package set and run some as-best-I-can stopwatch tests. The reason is the patch helps but my intuition tells me the apps are not opening as fast as the Oct. 30 package set.
I notice the commented lines are from commits 37a8b8a9 and 79dfe5ba of Nov. 4, which at least fits the time frame in question. From my perspective then, looks like some of the style engine work is indeed affecting app launch times. Hopefully they can be resolved. :)
Swapping package sets takes a while. :) Eventually I'll present some crude stopwatch benchmarks. :)
Here are my best-I-can stopwatch benchmarks. All times in seconds. Each time I flushed the ksycoca cache and restarted Trinity.
GIT short version 8443, Oct. 30
kate: 1.54, 1.29, 1.35; avg.: 1.39 konqueror: 1.47, 1.61, 1.57; avg.: 1.55 kmail: 2.09, 1.96, 1.97; avg.: 2.01
GIT short version 8665, Nov. 10, patched
kate: 1.68, 1.89, 1.73; avg.: 1.77 konqueror: 3.20, 2.81, 2.52; avg.: 2.84 kmail: 3.37, 3.47, 3.29; avg.: 3.38
GIT short version 8665, Nov. 10, unpatched
kate: 1.97, 1.94, 1.80; avg.: 1.90 konqueror: 3.60, 2.83, 3.21; avg.: 3.21 kmail: 3.72, 3.39, 3.47; avg.: 3.53
In the 8665 build there is a nominal improvement with the patch but either way, there is noticeable difference between the package sets. Enough that all users will notice. I'm running on a decent machine but I suspect users with less older hardware will notice more. :)
Darrell
Where are you getting the GIT short versions from?
What TDE widget style are you using?
And finally, can you/would you be willing to bisect the GIT tree to find the offending commit?
Thanks!
Tim
If you do choose to track down the offending commit, these are the commits that are most likely to have had an impact on execution speed:
http://git.trinitydesktop.org/cgit/tqt3/commit/src/styles/qcommonstyle.cpp?i... http://git.trinitydesktop.org/cgit/tqt3/commit/src/styles/qcommonstyle.cpp?i... http://git.trinitydesktop.org/cgit/tqt3/commit/src/styles/qcommonstyle.cpp?i...
I would try reversing all three and verify that the slow loading issue disappears, then apply each one in turn to see which once caused the problem.
Tim
Where are you getting the GIT short versions from?
GIT_VERSION="`git shortlog . | grep -E '^[ ]+\w+' | wc -l`"
What TDE widget style are you using?
I use KDE 2 window decoration and KDE Classic widget style. I don't use themes.
And finally, can you/would you be willing to bisect the GIT tree to find the offending commit?
Sure, I'm willing but don't know how. Further, which module should be bisected? tqt3? tdelibs? tdebase? All three?
With that said, the lines you asked me to comment out were from commits 37a8b8a9 and 79dfe5ba of Nov. 4, which fits the time frame in question. That is, I see no slowness in launch times from my Oct. 30 package set but see them in my Nov. 10 package set.
Darrell
Where are you getting the GIT short versions from?
GIT_VERSION="`git shortlog . | grep -E '^[ ]+\w+' | wc -l`"
What TDE widget style are you using?
I use KDE 2 window decoration and KDE Classic widget style. I don't use themes.
And finally, can you/would you be willing to bisect the GIT tree to find the offending commit?
Sure, I'm willing but don't know how. Further, which module should be bisected? tqt3? tdelibs? tdebase? All three?
With that said, the lines you asked me to comment out were from commits 37a8b8a9 and 79dfe5ba of Nov. 4, which fits the time frame in question. That is, I see no slowness in launch times from my Oct. 30 package set but see them in my Nov. 10 package set.
Darrell
I dug a bit deeper into the cachegrind results with tdecachegrind and spotted an obscure codepath that was responsible for a significant fraction of the startup instructions. I have committed a patch for that problem in GIT hash 30c5994; can you please rebuild TQt3 and see if the slow startup time is resolved? You don't have to rebuild tdelibs or anything else, just TQt3.
Thanks!
Tim
I dug a bit deeper into the cachegrind results with tdecachegrind and spotted an obscure codepath that was responsible for a significant fraction of the startup instructions. I have committed a patch for that problem in GIT hash 30c5994; can you please rebuild TQt3 and see if the slow startup time is resolved? You don't have to rebuild tdelibs or anything else, just TQt3.
I rebuilt tqt3 with the latest commit. My stopwatch tests:
GIT shortlog version 8443, Oct. 30
kate: 1.54, 1.29, 1.35; avg.: 1.39 konqueror: 1.47, 1.61, 1.57; avg.: 1.55 kmail: 2.09, 1.96, 1.97; avg.: 2.01
GIT shortlog version 8665, Nov. 10, tqt3 patched with commit 30c5994
kate: 1.84, 1.50, 1.51; avg.: 1.62 konqueror: 1.70, 1.73, 1.70; avg.: 1.71 kmail: 2.48, 2.58, 2.49; avg.: 2.52
GIT shortlog version 8665, Nov. 10, tqt3 unpatched
kate: 1.97, 1.94, 1.80; avg.: 1.90 konqueror: 3.60, 2.83, 3.21; avg.: 3.21 kmail: 3.72, 3.39, 3.47; avg.: 3.53
Quantitatively, improved from the unpatched, slower than Oct. 30. Qualitatively, I notice but how much other users will notice remains unknown.
Darrell
I dug a bit deeper into the cachegrind results with tdecachegrind and spotted an obscure codepath that was responsible for a significant fraction of the startup instructions. I have committed a patch for that problem in GIT hash 30c5994; can you please rebuild TQt3 and see if the slow startup time is resolved? You don't have to rebuild tdelibs or anything else, just TQt3.
I rebuilt tqt3 with the latest commit. My stopwatch tests:
GIT shortlog version 8443, Oct. 30
kate: 1.54, 1.29, 1.35; avg.: 1.39 konqueror: 1.47, 1.61, 1.57; avg.: 1.55 kmail: 2.09, 1.96, 1.97; avg.: 2.01
GIT shortlog version 8665, Nov. 10, tqt3 patched with commit 30c5994
kate: 1.84, 1.50, 1.51; avg.: 1.62 konqueror: 1.70, 1.73, 1.70; avg.: 1.71 kmail: 2.48, 2.58, 2.49; avg.: 2.52
GIT shortlog version 8665, Nov. 10, tqt3 unpatched
kate: 1.97, 1.94, 1.80; avg.: 1.90 konqueror: 3.60, 2.83, 3.21; avg.: 3.21 kmail: 3.72, 3.39, 3.47; avg.: 3.53
Quantitatively, improved from the unpatched, slower than Oct. 30. Qualitatively, I notice but how much other users will notice remains unknown.
Darrell
OK, to debug further can you please run this using the latest GIT code: valgrind --tool=callgrind kmail --nofork immediately exit kmail, and send me the generated callgrind.out.<pid> file? I can then use that file to analyze the execution of the code on your machine and see if there is another suboptimal codepath in use.
At least the numbers are now generally within 1/2 second of the original numbers...
Thanks!
Tim
OK, to debug further can you please run this using the latest GIT code: valgrind --tool=callgrind kmail --nofork immediately exit kmail, and send me the generated callgrind.out.<pid> file? I can then use that file to analyze the execution of the code on your machine and see if there is another suboptimal codepath in use.
At least the numbers are now generally within 1/2 second of the original numbers...
kmail: http://humanreadable.nfshost.com/trinity/build_logs/callgrind.out.574
konqueror: http://humanreadable.nfshost.com/trinity/build_logs/callgrind.out.19425
kate: http://humanreadable.nfshost.com/trinity/build_logs/callgrind.out.21982
Darrell
OK, to debug further can you please run this using the latest GIT code: valgrind --tool=callgrind kmail --nofork immediately exit kmail, and send me the generated callgrind.out.<pid> file? I can then use that file to analyze the execution of the code on your machine and see if there is another suboptimal codepath in use.
At least the numbers are now generally within 1/2 second of the original numbers...
kmail: http://humanreadable.nfshost.com/trinity/build_logs/callgrind.out.574
konqueror: http://humanreadable.nfshost.com/trinity/build_logs/callgrind.out.19425
kate: http://humanreadable.nfshost.com/trinity/build_logs/callgrind.out.21982
Darrell
Thank you for the callgrind logs. I have pushed a patchset into GIT that should speed things up considerably, however the style API/ABI broke as a result, so you will need to recompile TQt3, tdelibs,tdebase, tdeartwork, and the tde-style-* applications.
Tim
Thank you for the callgrind logs. I have pushed a patchset into GIT that should speed things up considerably, however the style API/ABI broke as a result, so you will need to recompile TQt3, tdelibs,tdebase, tdeartwork, and the tde-style-* applications.
Okay. I might as well be prudent and rebuild the entire package set rather than "hope" only a few packages need rebuilding. I won't be able to provide a status report for several hours. Status web page says GIT is operational so I'll start syncing and building.
Darrell
Thank you for the callgrind logs. I have pushed a patchset into GIT that should speed things up considerably, however the style API/ABI broke as a result, so you will need to recompile TQt3, tdelibs,tdebase, tdeartwork, and the tde-style-* applications.
The latest GIT is causing the following build failures in python-tqt:
sipqtTQCommonStyle.cpp:1584: error: cannot allocate an object of abstract type 'sipTQCommonStyle' sipqtTQStyle.cpp:2433: error: cannot allocate an object of abstract type 'sipTQStyle'
Could be related to bug report 1168.
Darrell
Thank you for the callgrind logs. I have pushed a patchset into GIT that should speed things up considerably, however the style API/ABI broke as a result, so you will need to recompile TQt3, tdelibs,tdebase, tdeartwork, and the tde-style-* applications.
The latest GIT is causing the following build failures in python-tqt:
sipqtTQCommonStyle.cpp:1584: error: cannot allocate an object of abstract type 'sipTQCommonStyle' sipqtTQStyle.cpp:2433: error: cannot allocate an object of abstract type 'sipTQStyle'
Could be related to bug report 1168.
Darrell
Hmm, that wasn't expected. Before I troubleshoot further, have you seen any speed increase as a result of the changes?
Thanks!
Tim
Hmm, that wasn't expected.
Of course, or you would have fixed already. :)
Before I troubleshoot further, have you seen any speed increase as a result of the changes?
I haven't got that far --- been a busy afternoon. :)
Darrell
Here is another build failure with the latest GIT. I can't find any file on my system containing the string "kdeui" in the file name or in the tdevelop.build directory. Something modifes tdevelop/lib/interfaces/external/CMakeLists.txt during the build to link to kdeui-shared. I don't see any patches to tdevelop in the past several days since my last full package set build.
make[2]: Entering directory `/dev/shm/tdevelop.build' /usr/bin/cmake -E cmake_progress_report /dev/shm/tdevelop.build/CMakeFiles [ 10%] Building CXX object lib/interfaces/external/CMakeFiles/kinterfacedesigner-shared.dir/designer.cpp.o cd /dev/shm/tdevelop.build/lib/interfaces/external && /usr/bin/c++ -Dkinterfacedesigner_shared_EXPORTS -DHAVE_CONFIG_H -DQT_NO_ASCII_CAST -DQT_CLEAN_NAMESPACE -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -DQT_THREAD_SUPPORT -D_REENTRANT -O2 -march=i486 -mtune=i686 -ggdb -include tqt.h -fPIC -I/dev/shm/tdevelop.build/lib/interfaces/external -I/opt/trinity/include -I/usr/include/tqt -include tqt.h -o CMakeFiles/kinterfacedesigner-shared.dir/designer.cpp.o -c /dev/shm/tdevelop/lib/interfaces/external/designer.cpp Linking CXX shared library libkinterfacedesigner.so cd /dev/shm/tdevelop.build/lib/interfaces/external && /usr/bin/cmake -E cmake_link_script CMakeFiles/kinterfacedesigner-shared.dir/link.txt --verbose=1 /usr/bin/c++ -fPIC -O2 -march=i486 -mtune=i686 -ggdb -include tqt.h -Wl,--no-undefined -shared -Wl,-soname,libkinterfacedesigner.so.0 -o libkinterfacedesigner.so.0.0.0 CMakeFiles/kinterfacedesigner-shared.dir/designer.cpp.o /opt/trinity/lib/libkparts.so.2.1.0 -lkdeui-shared /opt/trinity/lib/libkio.so.4.2.0 /opt/trinity/lib/libtdeui.so.4.2.0 -lfreetype -lfontconfig /opt/trinity/lib/libtdesu.so.4.2.0 -lutil /opt/trinity/lib/libkwalletclient.so.1.0.1 /opt/trinity/lib/libtdecore.so.4.2.0 /opt/trinity/lib/libDCOP.so.4.2.0 /opt/trinity/lib/libtdefx.so.4.2.0 -ltqt -ltqt-mt -lXrender -lX11 -lz -lidn -lXcomposite -lXfixes -lICE -lSM -ludev -lgamin-1 /usr/lib/gcc/i486-slackware-linux/4.4.4/../../../../i486-slackware-linux/bin/ld: cannot find -lkdeui-shared collect2: ld returned 1 exit status make[2]: *** [lib/interfaces/external/libkinterfacedesigner.so.0.0.0] Error 1 make[2]: Leaving directory `/dev/shm/tdevelop.build' make[1]: *** [lib/interfaces/external/CMakeFiles/kinterfacedesigner-shared.dir/all] Error 2 make[1]: Leaving directory `/dev/shm/tdevelop.build' make: *** [all] Error 2 There was an error trying to build tdevelop. EXIT_CODE: 1
Darrell
Hmm, that wasn't expected. Before I troubleshoot further, have you seen any speed increase as a result of the changes?
Latest stopwatch tests:
GIT shortlog version 8443, Oct. 30 (This is the original baseline)
kate: 1.54, 1.29, 1.35; avg.: 1.39 konqueror: 1.47, 1.61, 1.57; avg.: 1.55 kmail: 2.09, 1.96, 1.97; avg.: 2.01
GIT shortlog version 8582, Nov. 15 (This is from GIT early in the day)
kate: 1.32, 1.10, 1.04; avg.: 1.15 konqueror: 0.87, 0.90, 1.10; avg.: 0.96 kmail: 1.39, 1.39, 1.39; avg.: 1.39
I never saw konqueror open this fast and I always have used 1 preloaded instance. With a preloaded instance, this is the way konqueror should have always opened but never has.
Great!
Darrell
Hmm, that wasn't expected. Before I troubleshoot further, have you seen any speed increase as a result of the changes?
Latest stopwatch tests:
GIT shortlog version 8443, Oct. 30 (This is the original baseline)
kate: 1.54, 1.29, 1.35; avg.: 1.39 konqueror: 1.47, 1.61, 1.57; avg.: 1.55 kmail: 2.09, 1.96, 1.97; avg.: 2.01
GIT shortlog version 8582, Nov. 15 (This is from GIT early in the day)
kate: 1.32, 1.10, 1.04; avg.: 1.15 konqueror: 0.87, 0.90, 1.10; avg.: 0.96 kmail: 1.39, 1.39, 1.39; avg.: 1.39
I never saw konqueror open this fast and I always have used 1 preloaded instance. With a preloaded instance, this is the way konqueror should have always opened but never has.
Great!
Darrell
I'm glad to hear it worked, and it's an added bonus that the new version ended up being significantly faster than the original!
I will be working through the few build failures as time permits after the build farm is back up.
Tim
I'm glad to hear it worked, and it's an added bonus that the new version ended up being significantly faster than the original!
I will be working through the few build failures as time permits after the build farm is back up.
There might be additional failures with the various tdebindings support packages. Because python-tqt is the first in the chain, and that module failed to build, I did not build the others or tdebindings. Whether the remainder have similar problems is unknown until python-tqt is patched.
I found the cause of the build failure with tdevelop. I had forgotten I was testing a patch for bug report 1262. Without the patch tdevelop builds. Thus the latest style engine patches are not related.
Darrell
On Friday 16 of November 2012 06:07:31 Darrell Anderson wrote:
I found the cause of the build failure with tdevelop. I had forgotten I was testing a patch for bug report 1262. Without the patch tdevelop builds. Thus the latest style engine patches are not related.
Darrell
Note: Patch in bug 1262 was updated - you can try rebuild with new patch - see attachment 983.
Slavek --
I will be working through the few build failures as time permits after the build farm is back up.
There might be additional failures with the various tdebindings support packages. Because python-tqt is the first in the chain, and that module failed to build, I did not build the others or tdebindings. Whether the remainder have similar problems is unknown until python-tqt is patched.
I found the cause of the build failure with tdevelop. I had forgotten I was testing a patch for bug report 1262. Without the patch tdevelop builds. Thus the latest style engine patches are not related.
koffice FTBFS too. I'm testing a patch.
Darrell
I will be working through the few build failures as time permits after the build farm is back up.
There might be additional failures with the various tdebindings support packages. Because python-tqt is the first in the chain, and that module failed to build, I did not build the others or tdebindings. Whether the remainder have similar problems is unknown until python-tqt is patched.
I found the cause of the build failure with tdevelop. I had forgotten I was testing a patch for bug report 1262. Without the patch tdevelop builds. Thus the latest style engine patches are not related.
koffice FTBFS too. I'm testing a patch.
Darrell
I just committed a patch for python-tqt; I assume your patch is doing something similar?
Tim
I just committed a patch for python-tqt; I assume your patch is doing something similar?
Yes, similar. I just copied the patterns from the other recent patches. I'm still building koffice.
I'll test python-tqt and the tdebindings chain when koffice is done.
Darrell
I just committed a patch for python-tqt; I assume your patch is doing something similar?
Yes, similar. I just copied the patterns from the other recent patches. I'm still building koffice.
I'll test python-tqt and the tdebindings chain when koffice is done.
Looks like my koffice patch works. Do you want me to push?
I am now building the tdebindings chain.
Darrell
Tim, would the recent style engine patches cause apps to open slowly?
It is possible, though that would definitely be considered a bug! I will run konqueror through callgrind and see if anything pops out.
I consider this a bug too. :)
I created a patch to comment out lines 619-621 of tqt3/src/styles/qcommonstyle.cpp. I am rebuilding tqt3 now. I should have results soon.
There is no doubt there is a difference. My package set from Oct. 30 does not exhibit the slowness. Add kate to the list as well.
Running apps from konsole reveals nothing. From that limited perspective all seems well, which is not the case. Nothing noticeable in the xsession-error log.
Darrell
2012/11/13 Darrell Anderson humanreadable@yahoo.com:
I'm using the latest GIT.
I haven't done any deep digging but there is no doubt that Konqueror is opening much slower than I am accustomed. Any request to open Konqueror takes two or more seconds. This is a dual core system with 8GB RAM and SATA II disks.
I have not seen this problem before. Only recently.
I have an instance preloaded and always have had that option enabled, but what I see indicates this is not happening. Could there have been a patch in the past few weeks that is affecting preloading?
I checked Konqueror in a virtual machine using a GIT package set that hasn't been updated in a couple of months. There, Konqueror opened right away, thereby confirming my observations in my normal system.
A fresh profile makes no difference.
Anybody else noticing this?
Um, KMail too.
I reverted to my package set from GIT short version 8443 Oct. 30 and both Konqueror and KMail again open quickly.
Tim, would the recent style engine patches cause apps to open slowly?
Darrell
Try running apps from the terminal emulator, there could be useful warnings. I had similar problem with KDE4 (sorry :) ) some time ago and warnings gave a clue that applications were recreating the shared cache on startup (actually there were more problems but that's another story). -- WBR, Vadim Zhukov
-
Darrell Anderson -
Slávek Banko -
Timothy Pearson -
Vadim Zhukov