On Tue, Apr 09, 2013 at 10:24:45PM -0400, Bob Rogers wrote:
map should produce better code and does reads better but it also
iterates the entire list and you can't break out of it . . .
Not quite true, as you can goto a label outside of the block:
sub find_odd {
# Return
From: Gyepi SAM gy...@praxis-sw.com
Date: Wed, 10 Apr 2013 13:54:06 -0400
On Tue, Apr 09, 2013 at 10:24:45PM -0400, Bob Rogers wrote:
Not quite true, as you can goto a label outside of the block:
[first example omitted]
Indeed, you are correct. However, when you break
On Wed, Apr 10, 2013 at 1:53 PM, Bob Rogers rogers-...@rgrjr.dyndns.org wrote:
From: Gyepi SAM gy...@praxis-sw.com
Date: Wed, 10 Apr 2013 13:54:06 -0400
On Tue, Apr 09, 2013 at 10:24:45PM -0400, Bob Rogers wrote:
[...]
Because your example handles a single result, it is not clear
From: Ben Tilly bti...@gmail.com
Date: Wed, 10 Apr 2013 14:09:19 -0700
On Wed, Apr 10, 2013 at 1:53 PM, Bob Rogers rogers-...@rgrjr.dyndns.org
wrote:
I would hope (but don't know how to check) that Perl is smart enough to
notice that the map in my original example is in a void
From: Gyepi SAM gy...@praxis-sw.com
Date: Mon, 8 Apr 2013 15:02:55 -0400
On Mon, Apr 08, 2013 at 10:54:47AM -0400, Ricker, William wrote:
Have we mentioned the other solution?
The Implicit loops of map {block} list; should produce more
optimized code and reads better too.
On Fri, Apr 05, 2013 at 09:20:16PM -0400, Jerrad Pierce wrote:
Regardless, my understanding was that although perl's sub calls are
somewhat expensive ...
I think it's *method calls* that are expensive, not subroutine calls.
The reason being that the subroutine that a method resolves to can
On Fri, Apr 5, 2013 at 8:22 PM, Jerrad Pierce belg4...@pthbb.org wrote:
at each level of recursion. What seems to be the case though is that when
we start going bac
up the stack that memory doesn't seem to be released at each pop. If, say,
at max depth
500mb of ram has been allocated I
Are languages that have mark and sweep garbage collection better about
returning memory to the system than languages like Perl that use reference
count garbage collection.
Also if you really want to see how and why Perl is using memory, take a
look at Tim Bunce's
David Larochelle writes:
Are languages that have mark and sweep garbage collection better about
returning memory to the system than languages like Perl that use reference
count garbage collection.
Not in practice.
While that potential is there, in it is not utilized. Most programs that
On Sat, Apr 06, 2013 at 09:11:55AM -0400, David Larochelle wrote:
Are languages that have mark and sweep garbage collection better about
returning memory to the system than languages like Perl that use reference
count garbage collection.
Not usually. On Unix systems, at least, memory is
On Sat, Apr 6, 2013 at 12:20 AM, Conor Walsh c...@adverb.ly wrote:
Ah! Ok, so maybe I was confused about this. Even if I set the last
reference to an object to undef perl will keep the memory until exit? The
high water mark for memory usage never goes down? Well, that is fine I
suppose, it
On Fri, Apr 5, 2013 at 8:22 PM, Jerrad Pierce belg4...@pthbb.org wrote:
at each level of recursion. What seems to be the case though is that when we
start going bac
up the stack that memory doesn't seem to be released at each pop. If, say, at
max depth
500mb of ram has been allocated I don't see
On Sat, Apr 6, 2013 at 12:30 PM, Bill Ricker bill.n1...@gmail.com wrote:
On Sat, Apr 6, 2013 at 12:20 AM, Conor Walsh c...@adverb.ly wrote:
Ah! Ok, so maybe I was confused about this. Even if I set the last
reference to an object to undef perl will keep the memory until exit? The
high water
On 04/06/2013 10:30 AM, John Redford wrote:
David Larochelle writes:
Are languages that have mark and sweep garbage collection better about
returning memory to the system than languages like Perl that use reference
count garbage collection.
Programs that want to do this kind of thing --
Uri Guttman writes:
mmap won't help with returning ram to the system. there is still a
malloc/free
involved and that will come from the same place as the rest of ram. the
only
way to return virtual ram is by lowering the top virtual address with
brk()/sbrk()
calls. and that needs contiguous
I am currently in the midst of implementing a fairly non-trivial recursive
algorithm in Perl. The depth of the recursion is quite large, so much so that I
have set no warning recursion which warns with a depth over 100. This seems
pretty small to me! If the default is to warn at a depth of 100
On Apr 5, 2013 8:24 PM, Uri Guttman u...@stemsystems.com wrote:
as for your ram usage, all recursions can be unrolled into plain loops by
managing your own stack. this is a classic way to save ram and sub call
overhead. with perl it would be a fairly trivial thing to do. use an array
for the
On Fri, Apr 5, 2013 at 6:03 PM, Conor Walsh c...@adverb.ly wrote:
On Apr 5, 2013 8:24 PM, Uri Guttman u...@stemsystems.com wrote:
as for your ram usage, all recursions can be unrolled into plain loops by
managing your own stack. this is a classic way to save ram and sub call
overhead. with
Detailed? What's kept beyond a called b (arguments...) ? That's not a
lot of bytes, unless it's complete deep copies of structures.
-C.
On Apr 5, 2013 9:08 PM, Ben Tilly bti...@gmail.com wrote:
On Fri, Apr 5, 2013 at 6:03 PM, Conor Walsh c...@adverb.ly wrote:
On Apr 5, 2013 8:24 PM, Uri
Detailed? What's kept beyond a called b (arguments...) ? That's not a
lot of bytes, unless it's complete deep copies of structures.
perldoc -f caller
package, line number, etc.
Regardless, my understanding was that although perl's sub calls are
somewhat expensive to some other languages that
THEORY
Ever general computer science over-simplification has a BUT that is very
important.
Recursion is as efficient as iteration ...
... IF AND ONLY IF Tail Recursion Optimization is in effect.
When Tail Recursion is in effect, you do NOT have all that call stack,
you're only one level down
On Fri, Apr 5, 2013 at 6:39 PM, Bill Ricker bill.n1...@gmail.com wrote:
THEORY
Ever general computer science over-simplification has a BUT that is very
important.
Recursion is as efficient as iteration ...
... IF AND ONLY IF Tail Recursion Optimization is in effect.
When Tail Recursion is
On Fri, Apr 5, 2013 at 9:51 PM, Ben Tilly bti...@gmail.com wrote:
When in doubt, benchmark.
I always doubt my benchmarks.
I also doubt benchmarks, but doubt extrapolating from theory
to reality even more.
--
Bill
@n1vux bill.n1...@gmail.com
On Fri, Apr 05, 2013 at 09:03:13PM -0400, Conor Walsh wrote:
why is this that much faster than actual recursion? That speaks
poorly of lowercase-p perl.
This is not a perl specific issue (for the most part).
Most languages that support function calls need to maintain an activation
record for
function calls are relatively expensive.
Certainly more so than iteration or array operations.
Maybe we could get a new pragma:
no overhead 'subs';
;/
I've been fighting a perl script problem for a while now
and just recently figured out a potential solution
that just happens to involve a
Date: Fri, 05 Apr 2013 20:23:30 -0400
From: Uri Guttman u...@stemsystems.com
To: boston-pm@mail.pm.org
Subject: Re: [Boston.pm] Perl and recursion
Message-ID: 515f6b02.70...@stemsystems.com
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 04/05/2013 08:13 PM, Adam Russell wrote:
I
at each level of recursion. What seems to be the case though is that when we
start going bac
up the stack that memory doesn't seem to be released at each pop. If, say, at
max depth
500mb of ram has been allocated I don't see that released at any point except
for when
perl exits and then of
On 04/05/2013 11:22 PM, Jerrad Pierce wrote:
at each level of recursion. What seems to be the case though is that when we
start going bac
up the stack that memory doesn't seem to be released at each pop. If, say, at
max depth
500mb of ram has been allocated I don't see that released at any
at each level of recursion. What seems to be the case though is that when we
start going bac
up the stack that memory doesn't seem to be released at each pop. If, say,
at max depth
500mb of ram has been allocated I don't see that released at any point
except for when
perl exits and then
On 4/6/2013 12:01 AM, Adam Russell wrote:
Ah! Ok, so maybe I was confused about this. Even if I set the last
reference to an object to undef perl will keep the memory until exit?
The high water mark for memory usage never goes down? Well, that is
fine I suppose, it isn't like this process will
30 matches
Mail list logo
