Red Hat Bugzilla – Bug 590727
var tracking issues with various kde applications
Last modified: 2010-05-10 11:22:32 EDT
Symptoms similar to past issues like bug #538233 seem to have resurfaced lately, on my own box, I see this trying to build both kdepim and konversation
$ rpm -q gcc
I compared past and recent build-times in koji, and these don't seem to vary much, so maybe it's something particular to my own box that has updates-testing enabled.
I'll keep digging for reproducers in the meantime.
You need to be more factual, on which sources, what g++ command line options, attach preprocessed sources. And, how long is too slow (for the insanely huge routines KDE uses so much)? Is the var-tracking limit reached or not?
The generated debug info quality increased quite a lot over the last few months
and in some cases it means more values tracked in var-tracking, which on these several thousand basic blocks long functions isn't exactly cheap.
OK, it seems to take a little while for problematic files, but not nearly as bad as it was previously.
For example, konversation now takes ~5 minutes longer (on a fast builder) than when using -fno-var-tracking-assignments
I'll do some more tests, but these slightly longer times seems to be acceptable for the extra work being done. so, consider it not an issue unless I find something 'really bad'(tm)
We definitely intend to work on var-tracking speed improvements (especially Alex Oliva), on the other side have several big projects which severely improve debug info quality at the expense of tracking yet more stuff.
~5 minutes longer compilation on huge functions is bad, but not extremely high priority - that would be for something taking hours to build or eating way too much memory or a significant slowdown across large codebase.