Description of problem: The Fedora version of Perl is build with debugging support (see perl -V |grep DEBUGGING). This causes 25-40% slowdown for my application (mod_perl based) when compared to running the same version of Perl without DEBUGGING. Version-Release number of selected component (if applicable): perl-5.8.5-9 Steps to Reproduce: 1. perl -V | grep DEBUGGING Actual results: cc='gcc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm', cppflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING -fno-strict-aliasing -pipe -I/usr/local/include -I/usr/include/gdbm' Compile-time options: DEBUGGING MULTIPLICITY USE_ITHREADS USE_64_BIT_INT USE_64_BIT_ALL USE_LARGE_FILES PERL_IMPLICIT_CONTEXT Expected results: the same without -DDEBUGGING in cppflags and without DEBUGGING in Compile-time options. Additional info: This is probably because the default $RPM_OPT_FLAGS contain the "-g" switch, and Perl's ./Configure reads the "-g" in CFLAGS as an order to build the debugging version of Perl. The following change to perl.spec should help: - sh Configure -des -Doptimize="$RPM_OPT_FLAGS" \ + sh Configure -des -Doptimize="`echo $RPM_OPT_FLAGS | sed 's/-g //'`" \
Created attachment 113734 [details] Disable -DDEBUGGING According to docs, the extra -DDEBUGGING is indeed probably most useful for folks hacking on Perl's internals. However, -g is standard for all packages in FC, so here's another approach that preserves it, but avoids addition of -DDEBUGGING. If I understand correctly, this would preserve most of the ability to debug Perl (with the -debuginfo package) and possible core dumps from it, but eliminate the performance overhead. I took a brief look at how this is handled in a few other distros' packages: - Debian builds a completely separate perl-debug package. - SuSE doesn't seem to have anything related in their specfile. - Mandriva has some implementation for flagging a debug/not debug build in their specfile (default: no debug) but they fail to take into account that if $RPM_OPT_FLAGS contains "-g", -DDEBUGGING is enabled by Configure, so I guess they're failing to produce the intended results. Call me conservative, but considering -DDEBUGGING has been (inadvertantly?) on for quite a long time in FC perls, I tend to think this is something to look into after FC4. The effect on already compiled binary modules is not entirely clear to me either, but it smells like this wouldn't cause any trouble.
I have tried to upgrade perl to my patched binary without -DDEBUGGING, and apparently my modules are still working (including binary ones such as Storable, DBD::Oracle, Crypt::SHA1, etc.).
Let's test perl built this way and we'll consider this for FC4, but more likely for FC5.
Warren, while you're rolling the Rawhide Perl updates, could you slip this one in (patch in comment 1) so more people could start testing?
This bug bites again! It seems it causes bug #514942, complicating the review bug #512726. The patch got lost during the update to 5.10.0. Fortunately, with 5.10.0, no patch is needed, configure option -DDEBUGGING=-g does the trick. I guess that the Release notes should mention that unlike in Fedora 9--11, perl in Fedora 12 is compiled without -DDEBUGGING again.
(In reply to comment #5) > I guess that the Release notes should mention that unlike in Fedora 9--11, perl > in Fedora 12 is compiled without -DDEBUGGING again. No, the fix will probably come with perl 5.10.1 in F-13. I'm afraid we won't have a production build of perl in F-12. After all, no one noticed for three releases of Fedora...
(In reply to comment #6) > (In reply to comment #5) > > I guess that the Release notes should mention that unlike in Fedora 9--11, perl > > in Fedora 12 is compiled without -DDEBUGGING again. > > No, the fix will probably come with perl 5.10.1 in F-13. > I'm afraid we won't have a production build of perl in F-12. After all, no one > noticed for three releases of Fedora... Either that, or rebuild all the arch-specific perl-* packages out there after making this change. That wouldn't be too complex (create a tag; loop, bump & build to the tag; merge back to dist-f12); but it would be a lot of churn for the middle of a beta cycle. (Not that far more complicated changes haven't been introduced around this point before...)
(In reply to comment #7) > That wouldn't be too complex (create a tag; [...] This was also my first impression when I discovered this problem. Fortunately, I do not have the rights to create a tag; I had to apply for it. A discussion followed, I had to advocate that I really need the tag; as time passed, I began to see more consequences and decided that this change is not as easy as it seems to be. First, I want to have dependencies right. My own system is randomly updated rawhide: at random times, I do "yum update some-packages" and I suppose that the dependencies are there mo ensure that everything works. Currently, Fedora has debug perl and debug modules, i.e., all were compiled with -DDEBUGGING. We would like to get have production perl and production modules. But debug modules do not work with production perl. The dependencies should reflect this. So the current debug modules have to require something that will not be provided by the production perl. What could that be? I cannot invent anything better than perl(:MODULE_COMPAT_5.10.0) So our final production perl may not provide that; it will provide perl(:MODULE_COMPAT_5.10.1) instead. But at beginning of August, when I consideres this move, there was still no 5.10.1 release candidate available. Top be able to do this, I would have to start by creating a snapshot labeled 5.10.1rc0 or some such. (The following week the alpha was postponed. But I afraid they didn't mean it as an opprtunity to start something that might then cause anither slip.) This was the main reason why I decide to leave fixing this bug for early dist-f13. But there were also two supportive reasons: Reason 1: I wanted to do exactly what Chris said: > create a tag; loop, bump & build to the tag; merge back to dist-f12 But that building to the tag is actually bootstrapping; you have to respect the BuildRequires and Requires. In theory, that should be easy. But we are not a source distribution, you cannot just "make world", so this is something which is not tested yet, so something is bound to break. And, indeed, Tom spot Callaway witnessed from his work on packaging 5.10.0 that such a bootstrap is a real PITA. Reason 2: Moreover, this is not the only change bound to the version number increase. The other one was advertised here: http://article.gmane.org/gmane.linux.redhat.fedora.perl/9664 > [...] but it would be a lot of churn for the middle of a beta cycle. Another consequence of asking for the tag was that they adverted me from my idea to slip in during the beta period. The risks are not worth the gain. I hope this all explains why we will (almost surely) stay with debug perl for Fedora 12. This comment does not discuss whether the change should be done using a separate tag or not. But that's an implementation issue that can be discussed on the fedora-perl-devel-list. [the "patch" keyword is no longer relevant]
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
(In reply to comment #6) > (In reply to comment #5) > > I guess that the Release notes should mention that unlike in Fedora 9--11, perl > > in Fedora 12 is compiled without -DDEBUGGING again. > > No, the fix will probably come with perl 5.10.1 in F-13. Is this still planned for F-13? When should this rebuild start?
I believe we are since F-13 without debug. The configure is using macro DDEBUGGING=-g which should be the correct way (comment #5). In case it still doesn't work, please reopen.