[32387] in Perl-Users-Digest
Perl-Users Digest, Issue: 3654 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sat Mar 31 14:09:26 2012
Date: Sat, 31 Mar 2012 11:09:06 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Sat, 31 Mar 2012 Volume: 11 Number: 3654
Today's topics:
Re: How to speed up this slow part of my program <justin.1203@purestblue.com>
Re: How to speed up this slow part of my program <justin.1203@purestblue.com>
Re: How to speed up this slow part of my program <rvtol+usenet@xs4all.nl>
Re: How to speed up this slow part of my program <glex_no-spam@qwest-spam-no.invalid>
Re: How to speed up this slow part of my program <rweikusat@mssgmbh.com>
Re: reason for local($_) ? (Tim McDaniel)
Re: reason for local($_) ? <ben@morrow.me.uk>
Re: reason for local($_) ? <*@eli.users.panix.com>
Retraction of a claim about File::Slurp (was: string va <rweikusat@mssgmbh.com>
string variable to hold a lengthy string <John.Smith@invalid.com>
Re: string variable to hold a lengthy string <m@rtij.nl.invlalid>
Re: string variable to hold a lengthy string <rweikusat@mssgmbh.com>
Re: string variable to hold a lengthy string <John.Smith@invalid.com>
Re: string variable to hold a lengthy string (Tim McDaniel)
Re: string variable to hold a lengthy string <glex_no-spam@qwest-spam-no.invalid>
Re: string variable to hold a lengthy string <ben@morrow.me.uk>
Re: string variable to hold a lengthy string <jurgenex@hotmail.com>
Re: string variable to hold a lengthy string <ben@morrow.me.uk>
Re: string variable to hold a lengthy string <hjp-usenet2@hjp.at>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 30 Mar 2012 14:05:44 +0100
From: Justin C <justin.1203@purestblue.com>
Subject: Re: How to speed up this slow part of my program
Message-Id: <8mng49-266.ln1@zem.masonsmusic.co.uk>
On 2012-03-29, J. Gleixner <glex_no-spam@qwest-spam-no.invalid> wrote:
> On 03/28/12 10:24, Justin C wrote:
>> We have a database of thousands of clothing items. Some of the items are
>> almost identical apart from their size. Consequently we use the same
>> image in our web-shop to advertise items of the same style, design and
>> colour.
>>[...]
>> The bottle-neck, as I see it, is running grep 20k times, once for each
>> image found. Can anyone suggest a better way?
>
> Since you already have data in a DB, I'd suggest looking at
> associating these files, to the items, in the database.
>
> Maybe store the path to the file, or possibly the image as a BLOB, a
> many to one relationship.
Unfortunately it's not a DB I'm authorised to write to. I can run
queries that extract data, but any changes to the data must be done
through the 3rd party supplied interface.
Justin.
--
Justin C, by the sea.
------------------------------
Date: Fri, 30 Mar 2012 14:00:43 +0100
From: Justin C <justin.1203@purestblue.com>
Subject: Re: How to speed up this slow part of my program
Message-Id: <rcng49-266.ln1@zem.masonsmusic.co.uk>
On 2012-03-28, Ben Morrow <ben@morrow.me.uk> wrote:
>
> Quoth Justin C <justin.1203@purestblue.com>:
>>
>> We have a database of thousands of clothing items. Some of the items are
>> almost identical apart from their size. Consequently we use the same
>> image in our web-shop to advertise items of the same style, design and
>> colour.
>>
>> In a program I have to get new images from the art guy's computer I end
>> up grepping the entire list of items $#(list-of-items) times, there must
>> be a better way. The file names are exactly the same as the style codes
>> apart from the size suffix being dropped. I'm using File::Find.
>>
>> Here's some code:
>>
>> find(\&set_flag, (keys %{ $stock_groups->{text2code} }));
>>
>> sub set_flag {
>> return unless (-f $_ );
>>
>> (my $item_code_part = $_) =~ s/\.jpg//;
>> $item_code_part = uc($item_code_part);
>> $item_code_part =~ s|_|/|g;
>>
>> my @matches = grep(/$item_code_part/, keys %{ $stock_items });
>
> Careful: you want \Q there, even if you think you're sure the filenames
> are all safe.
Done that, thank you.
>> foreach my $i (@matches) {
>> $stock_items->{$i}{got_image} = 1;
>> }
>> }
>
> I would probably turn this into a big pattern match. Something like
> this:
>
> use File::Find::Rule;
>
> my ($imgs) = map qr/$_/, join "|", map "\Q\U$_",
> map { (my ($x) = /(.*)\.jpg/) =~ s!_!/!g; $x }
> File::Find::Rule->file->in(keys %{...});
>
> while (my ($item, $entry) = each %$stock_items) {
> $item =~ $imgs and $entry->{got_image} = 1;
> }
That takes a bit of understanding, I'll have a read of the docs.
> If you're using 5.14 you can get rid of the ugly map block using s///r
> and tr///r:
>
> map tr!_!/!r, map s/\.jpg//r,
Still on 5.10, we follow Debian 'stable' and so won't be upgrading for a
while.
Thanks for the suggestions.
Justin.
--
Justin C, by the sea.
------------------------------
Date: Fri, 30 Mar 2012 16:14:37 +0200
From: "Dr.Ruud" <rvtol+usenet@xs4all.nl>
Subject: Re: How to speed up this slow part of my program
Message-Id: <4f75bfcd$0$6847$e4fe514c@news2.news.xs4all.nl>
On 2012-03-28 17:24, Justin C wrote:
> We have a database of thousands of clothing items. Some of the items are
> almost identical apart from their size. Consequently we use the same
> image in our web-shop to advertise items of the same style, design and
> colour.
Are these (hard- or soft-) linked to a single file? If so, then you can
use that attribute.
--
Ruud
------------------------------
Date: Fri, 30 Mar 2012 09:58:19 -0500
From: "J. Gleixner" <glex_no-spam@qwest-spam-no.invalid>
Subject: Re: How to speed up this slow part of my program
Message-Id: <4f75ca0b$0$73604$815e3792@news.qwest.net>
On 03/30/12 08:05, Justin C wrote:
> On 2012-03-29, J. Gleixner<glex_no-spam@qwest-spam-no.invalid> wrote:
>> On 03/28/12 10:24, Justin C wrote:
>>> We have a database of thousands of clothing items. Some of the items are
>>> almost identical apart from their size. Consequently we use the same
>>> image in our web-shop to advertise items of the same style, design and
>>> colour.
>>> [...]
>>> The bottle-neck, as I see it, is running grep 20k times, once for each
>>> image found. Can anyone suggest a better way?
>>
>> Since you already have data in a DB, I'd suggest looking at
>> associating these files, to the items, in the database.
>>
>> Maybe store the path to the file, or possibly the image as a BLOB, a
>> many to one relationship.
>
> Unfortunately it's not a DB I'm authorised to write to. I can run
> queries that extract data, but any changes to the data must be done
> through the 3rd party supplied interface.
OK. Then put it in your own database. MySQL, Postgres, SQLite, even a
DBM file might work.
------------------------------
Date: Fri, 30 Mar 2012 16:29:07 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: How to speed up this slow part of my program
Message-Id: <878viiqf98.fsf@sapphire.mobileactivedefense.com>
"J. Gleixner" <glex_no-spam@qwest-spam-no.invalid> writes:
> On 03/30/12 08:05, Justin C wrote:
>> On 2012-03-29, J. Gleixner<glex_no-spam@qwest-spam-no.invalid> wrote:
>>> On 03/28/12 10:24, Justin C wrote:
>>>> We have a database of thousands of clothing items. Some of the items are
>>>> almost identical apart from their size. Consequently we use the same
>>>> image in our web-shop to advertise items of the same style, design and
>>>> colour.
>>>> [...]
>>>> The bottle-neck, as I see it, is running grep 20k times, once for each
>>>> image found. Can anyone suggest a better way?
>>>
>>> Since you already have data in a DB, I'd suggest looking at
>>> associating these files, to the items, in the database.
>>>
>>> Maybe store the path to the file, or possibly the image as a BLOB, a
>>> many to one relationship.
>>
>> Unfortunately it's not a DB I'm authorised to write to. I can run
>> queries that extract data, but any changes to the data must be done
>> through the 3rd party supplied interface.
>
> OK. Then put it in your own database. MySQL, Postgres, SQLite, even a
> DBM file might work.
This is a 'simple' key <-> value mapping, only complicated by the fact
that keys can have multiple values associating with them. Provided
that the code for a particular stock item can be calculated, the
simple first attempt at a solution would still be to use a Perl hash
mapping codes to sets of stock item keys. This hash can be generated
once in advance and then be used for any number of 'fast' lookups. A
more elaborate design would be to use a flat-file hashed database ('DBM
file') to store the mappings, update that whenever the set of stock
items changes and use it to associate presently existing images with
stock items without recalculating the mappings. An even better idea
would be to use a persistent database mapping stock items to image
files and update this database whenever the set of image files
changes.
------------------------------
Date: Thu, 29 Mar 2012 22:16:45 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: reason for local($_) ?
Message-Id: <jl2n0d$bgs$1@reader1.panix.com>
In article <ck1f49-plp.ln1@anubis.morrow.me.uk>,
Ben Morrow <ben@morrow.me.uk> wrote:
>
>Quoth tmcd@panix.com:
>>
>> Or, I suppose
>> while (my $_ = <>)
>> after every place I use Perl upgrades past 5.9.? or whatever it is that
>> first allowed "my $_".
>
>Be a little careful with 'my $_'. It currently breaks things like
>List::Util::first that call callbacks with a localised global $_.
Hrm?
first BLOCK LIST
Similar to "grep" in that it evaluates BLOCK setting $_ to
each element of LIST in turn. "first" returns the first
element where the result from BLOCK is a true value. If BLOCK
never returns true or LIST was empty then "undef" is returned.
$foo = first { defined($_) } @list
# first defined value in @list
$foo = first { $_ > $value } @list
# first value in @list which is greater than $value
So if I do them within the scope of "my $_", the $_ in the block I
provide ("$_ > $value" or whatever) will resolve to the lexical, not
to the global?
http://stackoverflow.com/questions/3393038/does-my-do-anything-if-is-implied
Evan Carroll (I think) quoted from "perldoc perl591delta" that
In a scope where $_ has been lexicalized, you can still have
access to the global version of $_ by using $::_, or, more simply,
by overriding the lexical declaration with "our $_".
After "our $_", note that $_ refers to the same global as was
available outside the lexical "my $_". You can use
local our $_ = EXPR;
to get the package variable with its own localized value.
http://www.effectiveperlprogramming.com/blog/1333 goes farther, to say
that lexical $_ is a bug and given() is unusable. I didn't read it in
any detail to know whether he's saying something useful or incorrect.
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Thu, 29 Mar 2012 23:59:38 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: reason for local($_) ?
Message-Id: <q36f49-10r.ln1@anubis.morrow.me.uk>
Quoth tmcd@panix.com:
> In article <ck1f49-plp.ln1@anubis.morrow.me.uk>,
> Ben Morrow <ben@morrow.me.uk> wrote:
> >
> >Be a little careful with 'my $_'. It currently breaks things like
> >List::Util::first that call callbacks with a localised global $_.
>
> Hrm?
>
> first BLOCK LIST
>
> Similar to "grep" in that it evaluates BLOCK setting $_ to
> each element of LIST in turn. "first" returns the first
> element where the result from BLOCK is a true value. If BLOCK
> never returns true or LIST was empty then "undef" is returned.
>
> $foo = first { defined($_) } @list
> # first defined value in @list
> $foo = first { $_ > $value } @list
> # first value in @list which is greater than $value
>
> So if I do them within the scope of "my $_", the $_ in the block I
> provide ("$_ > $value" or whatever) will resolve to the lexical, not
> to the global?
Exactly.
> In a scope where $_ has been lexicalized, you can still have
> access to the global version of $_ by using $::_, or, more simply,
> by overriding the lexical declaration with "our $_".
You can use this as a workaround, but it rather takes away the point of
using $_ in the first place. IMHO the correct solution is for first to
use the same interface to set the caller's $_ as is used by map and
grep, but I don't think that interface is currently available outside
the core.
Ben
------------------------------
Date: Fri, 30 Mar 2012 00:03:38 +0000 (UTC)
From: Eli the Bearded <*@eli.users.panix.com>
Subject: Re: reason for local($_) ?
Message-Id: <eli$1203291957@qz.little-neck.ny.us>
In comp.lang.perl.misc, Tim McDaniel <tmcd@panix.com> wrote:
> And I don't know that "local $_" should be slow, given that every map,
> grep, and foreach() has to do it.
My copy of _Programming Perl_ says "second edition" and "1996" on the
copyright page, so I know it is not up-to-date, but the sentence spanning
the page break of 108 to 109 says (with *stars* for bold):
By and large, you should prefer to use *my* over
*local* because it is faster and safer.
I've taken that to heart, and avoid needing to use local().
Elijah
------
doesn't know of local($_) gets special treatment
------------------------------
Date: Sat, 31 Mar 2012 16:13:54 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Retraction of a claim about File::Slurp (was: string variable to hold a lengthy string)
Message-Id: <87wr60iz0t.fsf_-_@sapphire.mobileactivedefense.com>
Rainer Weikusat <rweikusat@mssgmbh.com> writes:
[...]
> This roughly amounts to copying the string in sections and inserting
> $myvar instead of a %1 from the original string so the answer should
> be 'no'.
This obviously implies that my older claim that File::Slurp would
trigger use of an O(n*n) algortihm for 'Windows text file support' is
wrong: It would be true for an in-place substitution performed on the
input string because each individual substitution would require a copy
of the tail string and the total running time would be proportional to
the sum of the lengths of all tail strings which needed to be
copied. But at least for simple substitutions, perl doesn't do that
and while there's theoretically a similar problem with sequences of
copying reallocs, at least for my simple set of test cases and the
realloc implementation of the system I was using, this didn't happen.
OTOH, the 'linearity' of the Perl-level algorithm rests on
undocumented properties of the pp_subst implementation, which, in
turn, relies on undocumented properties of the system realloc, and
this is - in my opinion - extremely bad style and it is also prone to
cause 'maintenance surprises' because Perl will do an in-place
subsitutation in certain cases (read: The code is there and it is not
immediately obvious under which circumstance it is going to be
executed) and it is pretty certain that people won't do an in depth
analysis of this part of the perl implementation before changing a
s/// expression.
------------------------------
Date: Fri, 30 Mar 2012 18:15:07 +0300
From: John <John.Smith@invalid.com>
Subject: string variable to hold a lengthy string
Message-Id: <t5jbn7ta2kt8fkoi1qk78om70dloqn1q7f@4ax.com>
I have a rather lengthy string like this:
$page = <<HERE;
<input type="hidden" value="%1">
</form>
...(a couple hundred html lines)
HERE
$page=~s/%1/$myvar/ge;
print $page;
Is there some limit to how long a string the $page variable can hold?
Another question:
The the line
$page=~s/%1/$myvar/ge;
processes the lengthy string. Will I run into some limitations there?
will that cause problems?
------------------------------
Date: Fri, 30 Mar 2012 17:55:08 +0200
From: Martijn Lievaart <m@rtij.nl.invlalid>
Subject: Re: string variable to hold a lengthy string
Message-Id: <sj1h49-ro4.ln1@news.rtij.nl>
On Fri, 30 Mar 2012 18:15:07 +0300, John wrote:
> I have a rather lengthy string like this:
>
> $page = <<HERE;
> <input type="hidden" value="%1">
> </form>
> ...(a couple hundred html lines)
> HERE $page=~s/%1/$myvar/ge;
> print $page;
>
>
> Is there some limit to how long a string the $page variable can hold?
Limited by available memory. In other words, don't worry about it with
only a few hunderd lines. Start worrying at a few million, but you
probably will be fine even then.
> Another question:
> The the line $page=~s/%1/$myvar/ge;
> processes the lengthy string. Will I run into some limitations there?
> will that cause problems?
This should be fine, but why the /e modifier?
Where you can get into problems with regular expressions, is when you
need to backtrack often. In that case, you can get performance problems
with huge strings. But as you have no wildcards in your search pattern,
there is no risk of this.
And even in the case of an inefficient regular expression on a huge
string:
1) with modern fast machines, you probably won't notice anyhow; and
2) you probably need to read and write that string from/to disk/network,
which is relatively slow, so you won't notice anyhow.
HTH,
M4
M4
------------------------------
Date: Fri, 30 Mar 2012 17:23:29 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: string variable to hold a lengthy string
Message-Id: <871uoaqcqm.fsf@sapphire.mobileactivedefense.com>
John <John.Smith@invalid.com> writes:
> I have a rather lengthy string like this:
>
> $page = <<HERE;
> <input type="hidden" value="%1">
> </form>
> ...(a couple hundred html lines)
> HERE
> $page=~s/%1/$myvar/ge;
> print $page;
'A couple of hundred lines' is not 'lengthy' for an at least remotely
modern computer.
> Is there some limit to how long a string the $page variable can hold?
> Another question:
> The the line
> $page=~s/%1/$myvar/ge;
> processes the lengthy string. Will I run into some limitations there?
> will that cause problems?
This roughly amounts to copying the string in sections and inserting
$myvar instead of a %1 from the original string so the answer should
be 'no'. In particular, you won't be able to outperform the C code
which does this substitution copy with anything written in Perl.
------------------------------
Date: Fri, 30 Mar 2012 20:59:46 +0300
From: John <John.Smith@invalid.com>
Subject: Re: string variable to hold a lengthy string
Message-Id: <m1tbn79rmgr07152ka0eafj2s5fteim7cd@4ax.com>
Martijn Lievaart <m@rtij.nl.invlalid> wrote:
>On Fri, 30 Mar 2012 18:15:07 +0300, John wrote:
>
>> I have a rather lengthy string like this:
>>
>> $page = <<HERE;
>> <input type="hidden" value="%1">
>> </form>
>> ...(a couple hundred html lines)
>> HERE $page=~s/%1/$myvar/ge;
>> print $page;
>>
>>
>> Is there some limit to how long a string the $page variable can hold?
>
>Limited by available memory. In other words, don't worry about it with
>only a few hunderd lines. Start worrying at a few million, but you
>probably will be fine even then.
>
>> Another question:
>> The the line $page=~s/%1/$myvar/ge;
>> processes the lengthy string. Will I run into some limitations there?
>> will that cause problems?
>
>This should be fine, but why the /e modifier?
I am not sure about it too. Should it be there and if not please elaborate. I
took that from sample code.
------------------------------
Date: Fri, 30 Mar 2012 19:00:46 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: string variable to hold a lengthy string
Message-Id: <jl4vsu$8th$1@reader1.panix.com>
In article <m1tbn79rmgr07152ka0eafj2s5fteim7cd@4ax.com>,
John <John.Smith@invalid.com> wrote:
>Martijn Lievaart <m@rtij.nl.invlalid> wrote:
>
>>On Fri, 30 Mar 2012 18:15:07 +0300, John wrote:
>>> Another question:
>>> The the line $page=~s/%1/$myvar/ge;
>>> processes the lengthy string. Will I run into some limitations
>>> there? will that cause problems?
>>
>>This should be fine, but why the /e modifier?
>
>I am not sure about it too. Should it be there and if not please
>elaborate. I took that from sample code.
To know what it might be useful for, you can look at the
documentation. In this case, "man perlop", which explains about Perl
operators. A Google search for
"s///e" Perl
turns out not to be bad, which surprises me.
Anyway, from man perlop, I searched for /e. In less, that's
/\/e
I found, in Perl 5.8.8,
s/PATTERN/REPLACEMENT/egimosx
... A "/e" will cause the replacement portion to be treated as a
full-fledged Perl expression and evaluated right then and there.
It is, however, syntax checked at compile-time. A second "e"
modifier will cause the replacement portion to be "eval"ed before
being run as a Perl expression. ...
and explanations of g, i, m, o, s, and x. This is Perl 5.8; r and
maybe other modifiers have been added since.
The example code you provided showed that the string is HTML. Since
the right-hand side of the s/// does not require the full power of
Perl expressions, and since you merely want the variable substituted
in, you do not want to do /e.
The first Google hit is man perlrequick. I find it a little more
helpful:
http://perldoc.perl.org/perlrequick.html
The evaluation modifier s///e wraps an eval{...} around the
replacement string and the evaluated result is substituted for the
matched substring. Some examples:
# reverse all the words in a string
$x = "the cat in the hat";
$x =~ s/(\w+)/reverse $1/ge; # $x contains "eht tac ni eht tah"
# convert percentage to decimal
$x = "A 39% hit rate";
$x =~ s!(\d+)%!$1/100!e; # $x contains "A 0.39 hit rate"
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Fri, 30 Mar 2012 16:56:21 -0500
From: "J. Gleixner" <glex_no-spam@qwest-spam-no.invalid>
Subject: Re: string variable to hold a lengthy string
Message-Id: <4f762c05$0$52263$815e3792@news.qwest.net>
On 03/30/12 12:59, John wrote:
>>> I have a rather lengthy string like this:
>>>
>>> $page =<<HERE;
>>> <input type="hidden" value="%1">
>>> </form>
>>> ...(a couple hundred html lines)
>>> HERE $page=~s/%1/$myvar/ge;
>>> print $page;
[...]
Looks like the beginning of YATS (Yet Another Template System) :-)
You may want to look at using one of the many Template packages
already available, which will help you design something a little
better by following more of a MVC pattern. You would move those
'couple hundred html lines' out of your program and into another
file (template). Your program itself will be much shorter and
whatever you are doing it will be much easier to maintain/enhance.
http://search.cpan.org/search?query=template&mode=all
http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller
------------------------------
Date: Fri, 30 Mar 2012 23:25:02 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: string variable to hold a lengthy string
Message-Id: <ueoh49-cmd1.ln1@anubis.morrow.me.uk>
Quoth "J. Gleixner" <glex_no-spam@qwest-spam-no.invalid>:
>
> You may want to look at using one of the many Template packages
> already available, which will help you design something a little
> better by following more of a MVC pattern. You would move those
> 'couple hundred html lines' out of your program and into another
> file (template).
In an MVC system both the template and the code which expands it would
be considered part of the view. What you are talking about is the more
general question of separating code from data (which is an extremely
good idea); MVC is more about separating some bits of code from other
bits.
(Of course, some MVC systems, such as Catalyst, tend to implement the
view as such a thin layer over a templating module like TT2 that it's
easy to forget there's anything to the view but the templates.)
Ben
------------------------------
Date: Fri, 30 Mar 2012 17:09:54 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: string variable to hold a lengthy string
Message-Id: <2oicn7lngm6kjkiatnfm8rufqs9r4kdqi5@4ax.com>
John <John.Smith@invalid.com> wrote:
>I have a rather lengthy string like this:
>
>$page = <<HERE;
><input type="hidden" value="%1">
></form>
>...(a couple hundred html lines)
>HERE
>$page=~s/%1/$myvar/ge;
>print $page;
>
>
>Is there some limit to how long a string the $page variable can hold?
If I remember correctly from some discussions a long time ago in a
galaxy far away then there is a limit of something like 2GB.
But maybe that was for a 32-bit system, I don't quite remember.
jue
------------------------------
Date: Sat, 31 Mar 2012 01:45:48 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: string variable to hold a lengthy string
Message-Id: <sm0i49-m6f1.ln1@anubis.morrow.me.uk>
Quoth Jürgen Exner <jurgenex@hotmail.com>:
> John <John.Smith@invalid.com> wrote:
> >
> >Is there some limit to how long a string the $page variable can hold?
>
> If I remember correctly from some discussions a long time ago in a
> galaxy far away then there is a limit of something like 2GB.
> But maybe that was for a 32-bit system, I don't quite remember.
I think there used to be an (unnecessary) 2^32 limit, even on 64-bit
systems, but there isn't any more. 5.12 will quite happily create a
string longer than that on a 64-bit system (assuming you've got the
memory to hold it).
On a 32-bit system that limit still applies, obviously.
Ben
------------------------------
Date: Sat, 31 Mar 2012 10:39:47 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: string variable to hold a lengthy string
Message-Id: <slrnjndgmj.sl7.hjp-usenet2@hrunkner.hjp.at>
On 2012-03-31 00:45, Ben Morrow <ben@morrow.me.uk> wrote:
> Quoth Jürgen Exner <jurgenex@hotmail.com>:
>> John <John.Smith@invalid.com> wrote:
>> >
>> >Is there some limit to how long a string the $page variable can hold?
>>
>> If I remember correctly from some discussions a long time ago in a
>> galaxy far away then there is a limit of something like 2GB.
>> But maybe that was for a 32-bit system, I don't quite remember.
>
> I think there used to be an (unnecessary) 2^32 limit, even on 64-bit
> systems, but there isn't any more. 5.12 will quite happily create a
> string longer than that on a 64-bit system (assuming you've got the
> memory to hold it).
Same for 5.10.1 and 5.8.8. Haven't tried older versions.
hp
--
_ | Peter J. Holzer | Deprecating human carelessness and
|_|_) | Sysadmin WSR | ignorance has no successful track record.
| | | hjp@hjp.at |
__/ | http://www.hjp.at/ | -- Bill Code on asrg@irtf.org
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 3654
***************************************
