As hdb points out, it's in the spoiler at the end of my post.

It's not on cpan because I wrote it -- actually adapted it from some existing code -- in reponse to your OP.

I'd want to use a few times myself and see what else it needs before putting it out for general use. For starters it needs some error checking and Carp for when things go wrong.

It'd also be nice to use pack templates to allow for numeric fields; but then it I'd have to drop the lvalue-ness of the accessors.

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

Doh! I see it. This is very clever; compiled class and substr(). The only apparent downside is the fixed record length, but I could probably find a workable value for them. Given the roughly 5x overhead of Class::Struct, the savings ought to be well worth it. Let me PM you about error checking, etc. Thanks so much.

All in BrowserUk's post: http://perlmonks.org/?node_id=1037797;spoil=1

This is very clever! The only drawback is the fixed record length, but the savings is so significant compared to Class::Struct's ~5x overhead I should be able to find a workable size.

Let me PM you about error checking, etc. Thanks so very much.

Why does your solution use a compiled (eval) class? Is this faster or does it save memory vs. a solution like roboticus proposes?

Because it allows me to 'hardcode' the numbers in the substrs.

If you uncomment the print before the eval, you'll see something like:

package Test;
use constant { F1_N => 0, F2_N => 15, F3_N => 30, F4_N => 45, F5_N => 
+60, F6_N => 75, F7_N => 90, F8_N => 105, F9_N => 120, F10_N => 135, }
+;
use constant { F1_L => 15, F2_L => 15, F3_L => 15, F4_L => 15, F5_L =>
+ 15, F6_L => 15, F7_L => 15, F8_L => 15, F9_L => 15, F10_L => 15, };

sub new {
    my $class = shift;
    my $self = shift // '';
    return bless \$self, $class
}
# line 1 "sub_F4"
sub Test::F4 :lvalue {
    my $self = shift;
    substr( $$self, F4_N(), F4_L() );
}
[download]

F4_N() and F4_L() are constant subs which get optimised away during compilation, leaving hardcoded numbers which are faster than variables.

The memory saving comes from packing the fields into single strings; the performance comes from asking the sub to do as little as possible.

That said, by explaining that, I've spotted another couple of optimisations; and a potential bug. I'll get back to you with a revised version 2 days from now.

(A good reason for not uploading to cpan straight away :)

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

Okay, I totally understand that now; I had un-commented the print and not remembered that the 'use constant' actually does get optimised away at compile time. Very cool.

FWIW, I don't need the lvalue-ness of the accessors, setting them with param(value) makes me totally happy, especially if it saves anything. I'm embarrassed to say I've never seen the ":lvalue" attribute in use, which is rather nifty.

This is so promising. I really appreciate your expertise on this; I've tried various solutions like roboticus proposed, but performance has been unusable.