Joshua ben Jore wrote: > It has two benefits. Separating code from pod prevents it from being > wholely unreadable without syntax highlighting.
<snip> > The other benefit is you don't spend the CPU parsing that additional > bit of text. I recall noticing it on some really pod-heavy code. The former is arguable. The latter is a commonly held misconception. Here is how perl "parses" POD: when in code it looks for a /^=\w+/ outside of a statement, everything following is ignored until it hits a /^=cut$/ or eof. The end. Comments are more complicated to parse than POD, but nobody bemoans comments in the name of optimizing compile time. The only way that POD slows down load-times is by making perl read more lines of text off disk. As an optimization this is slicing things awful thin and there are far better places to look to gain back performance. Hell, loading strict and warnings takes more time yet you leave those in production code. Putting POD after __END__ means Perl doesn't even bother to read it in. To demonstrate this, compare inline POD, POD at the bottom and POD at __END__. Inline POD and POD at the bottom should load in equal time. POD at __END__ should also be indistinguishable unless you have a tremendous amount of POD. I had to put in 10k lines of POD before it had a measurable effect on load time (8ms vs 11ms) which was swamped by loading strict and warnings. This is on my Macbook, not some fancy server with fast disks. Its a red herring.
