in reply to Re^9: Perl 5 Optimizing Compiler, Part 4: LLVM Backend?
in thread Perl 5 Optimizing Compiler, Part 4: LLVM Backend?

You don't need to sign up for bitcard etc. You just need to run the perlbug command-line client.

As for it's 'just one line'. What actually has to happen is that *someone* has to read the links you've provided, understand the issue, decide whether your patch is the best way to fix the issue (perhaps there are other considerations?), write an informative commit message, run the test suite, push the commit, and deal with any fallout if the smokes start failing. And field any queries from other p5pers, even though they aren't necessarily the one who understands the issue.

Whereas a bug report / RT ticket gets emailed to every one on the p5p mailing list, and the person who most understands the issue and/or the one with the spare time to apply the patch gets to deal with it. And all correspondence is logged against the ticket for future reference.

Dave.

  • Comment on Re^10: Perl 5 Optimizing Compiler, Part 4: LLVM Backend?

Replies are listed 'Best First'.
Re^11: Perl 5 Optimizing Compiler, Part 4: LLVM Backend?
by jdporter (Paladin) on Aug 29, 2012 at 02:36 UTC
    ... and deal with any fallout if the smokes start failing.

    Do the smokes even deal with performance, or relative changes in performance? I'd be concerned that a "fix" might solve one performance problem in one corner of the space, and introduce others in other places.

[reply]
      No, smokes don't generally deal with performance.

      Dave.

[reply]
        Maybe that should change. Someone should compare Perl 5.10.1 against blead for time per opcode type on same machine on same Perl code. I've thought and tried in the past to modifying NYTProf to profile all opcodes, not just entersub and a couple POSIX C Lib named opcodes. Other projects like Mozilla and Microsoft routinely have performance teams that track degradation in speed. While Perl doesn't have anywhere close to corporate funding or salaried programmers working on it, some kind of crude report for finding order of magnitude slow downs between releases. Currently it takes individual programmers benchmarking their scripts on old and new perls to trace down performance problems. Most programmers just update their Perls and *assume* P5P did their diligence and didn't create a Vista. My ActivePerl 5.10.0 DLL is 873KB, Blead, same config (O1, 32bit Win32, Visual C, no DEBUGGING) is 1056KB. About a 20% difference. Why? I dont know. Is all that growth healthy? I dont know.
[reply]

In Section Meditations