In perl.git, the branch smoke-me/arc/rt126813-data-dumper-trailingcomma has been created
<http://perl5.git.perl.org/perl.git/commitdiff/f7c7cf019e72109d7d2b0f1b3bc36207291ff7a0?hp=0000000000000000000000000000000000000000> at f7c7cf019e72109d7d2b0f1b3bc36207291ff7a0 (commit) - Log ----------------------------------------------------------------- commit f7c7cf019e72109d7d2b0f1b3bc36207291ff7a0 Author: Aaron Crane <a...@cpan.org> Date: Mon Dec 7 22:49:19 2015 +0000 Data::Dumper: add Trailingcomma option This is as suggested in RT#126813. The refactoring to use a structure for the style variables has now paid off: the additional variable is mentioned only where it's directly relevant, rather than needing to be passed explicitly to every recursive call. M MANIFEST M dist/Data-Dumper/Dumper.pm M dist/Data-Dumper/Dumper.xs A dist/Data-Dumper/t/trailing_comma.t commit cb4f1632f7865631f0ef000c620b1e45eea2768d Author: Aaron Crane <a...@cpan.org> Date: Tue Dec 8 15:03:28 2015 +0000 Data::Dumper: replace pointer with local variable The recursive dumping function uses a "level" variable to keep track of how deep in the data structure it is. Previously, this variable was allocated on the stack at the top level, and a pointer to that stack variable was passed to each recursive invocation. Each recursive step was careful to increment and decrement the pointed-to value at the right time. The consequence of this approach is that understanding what's going involves mentally tracking this state throughout the entire thousand-line function. This change therefore replaces that pointer-to-mutable-int with a plain int parameter; when the dumper invokes itself recursively, it simply adds one to the level as needed. This seems much simpler to me. This may also be faster: not only is the pointer indirection removed for accesses to the variable, but on platforms where pointers are wider than I32 (including typical 64-bit systems), less memory is used on the stack for the call frames. M dist/Data-Dumper/Dumper.xs commit d7764d2f666bda3e5092595a3bc59d9d6e40e0c7 Author: Aaron Crane <a...@cpan.org> Date: Tue Dec 8 14:42:43 2015 +0000 Data::Dumper: move sortkeys setting into style struct On Perl 5.6, there is no sortsv() function available to XS code, so Data::Dumper used a Perl helper function. The name of that helper function was allocated as a (mortal) SV, but that was done lazily, the first time the helper was needed. This meant that the "sortkeys" C variable was mutable, and therefore it couldn't be easily moved to the struct. I think it's a better trade-off to allocate the SV in all cases under 5.6: when dumping a data structure containing no hashes, we now allocate this SV unnecessarily, but we save an extra pointer on the stack in every recursive call frame. In addition, Data::Dumper doesn't currently work on 5.6, so this change certainly doesn't make anything any worse. I've nonetheless attempted to restore 5.6 compatibility in this narrow area surrounding the sortkeys option: in particular, a sortsv() call appeared in code that was compiled under 5.6, but has now been moved to a block that's compiled only under later Perls. I haven't been able to test this change on 5.6, though. M dist/Data-Dumper/Dumper.xs commit 8363228285ab90c4c63cda3f96e0a4a28e843def Author: Aaron Crane <a...@cpan.org> Date: Tue Dec 8 11:56:18 2015 +0000 Data::Dumper: reorder elements of style struct Putting all the pointers and pointer-sized integers together at the start of the struct reduces the amount of wasted space on platforms where pointers are wider than ints. In particular, this should reduce the size of the style struct by eight bytes on typical 64-bit configurations. M dist/Data-Dumper/Dumper.xs commit 5d336c455966e3b9ecf84c830cdff217735243b7 Author: Aaron Crane <a...@cpan.org> Date: Tue Dec 8 11:31:43 2015 +0000 Data::Dumper: refactor XS implementation The are over a dozen variables that control the specifics of how Data::Dumper generates output, almost all of which remain unchanged while dumping a single set of objects. The previous implementation passed each of those control variables as a separate argument to the recursive DD_dump() function, which meant that DD_dump() took over two dozen parameters. This is already far beyond what seems reasonable, and the problem will only get worse in future as Data::Dumper acquires more features. This refactoring therefore extracts most of those style variables into a struct, and passes it to the recursive calls as a pointer-to-const. This is clearly of huge benefit for maintainability. In addition, it seems plausible that it will make dumping slightly faster, especially for deeply-nested data structures: requiring every recursive call to have its own copy of them on the stack meant that every call frame would take up more than a single cache line of stack space even on 32-bit platforms. Putting them all in a single struct means that this space is used only once per dump instead. "If you have a procedure with 10 parameters, you probably missed some." âAlan Perlis, Epigrams on Programming, ACM SIGPLAN Notices 17 (9), September 1982, pp. 7â13. http://pu.inf.uni-tuebingen.de/users/klaeren/epigrams.html M dist/Data-Dumper/Dumper.pm M dist/Data-Dumper/Dumper.xs ----------------------------------------------------------------------- -- Perl5 Master Repository
