[THIN] Re: Home directory and Profile Script
- From: "Braebaum, Neil" <Neil.Braebaum@xxxxxxxxxxxxxxxxx>
- To: <thin@xxxxxxxxxxxxx>
- Date: Thu, 20 Oct 2005 08:54:56 +0100
True, true.
But self-modifying is the way to go ;-)
One would think recursion was the work of the devil. <deity> knows
what's thought about inheritance and polymorphism.
Neil
> -----Original Message-----
> From: thin-bounce@xxxxxxxxxxxxx
> [mailto:thin-bounce@xxxxxxxxxxxxx] On Behalf Of Lilley, Brian
> Sent: 19 October 2005 18:02
> To: 'thin@xxxxxxxxxxxxx'
> Subject: [THIN] Re: Home directory and Profile Script
>
> hear hear Andrew, and you haven't even begun to worry about
> whether the recursive code is re-entrant or not.
>
> -----Original Message-----
> From: thin-bounce@xxxxxxxxxxxxx [mailto:thin-bounce@xxxxxxxxxxxxx]On
> Behalf Of Andrew Wood
> Sent: 19 October 2005 17:54
> To: thin@xxxxxxxxxxxxx
> Subject: [THIN] Re: Home directory and Profile Script
>
> Recursion is an inefficient process. I have not only
> suggested it, I believe it to be. I believe this because in
> terms of raw computing resource a recursive process will take
> more resource than a linear one. What I've asked is that you
> think about it too - have you done that yet? I used the quote
> as an example as he put it quite succinctly
>
> 'Do they just, like, stay hanging around until everything finishes? '
>
> Yep I'm saying exactly that - because that's what happens.
> The memory states have to be stored while your subroutine
> works its way through.
>
> Here's a bit of recursion -
>
> Recursive procedure 1
> [memory variables stored]
> Call recursive
> recursive procedure (2)
> [memory variables stored]
> call recursive
> recursive procedure (3)
> [memory variables stored]
> return
> return
> end
>
> So - the first lot 'hang around' until (2) finishes (2) hangs
> around until
> (3) finishes and so on and so forth. Its all memory sitting
> around being used. Not a problem in the example code above -
> but you go and start creating big arrays and populating data
> objects and that's a lot of hanging around. You start making
> networked data calls or reading files and you can end up with
> deadlocks.
>
> If they didn't 'hang around' you wouldn't get a stack heap
> error when it all goes wrong. If you reuse the variables then
> the recursion will fall over as when the procedure returns
> from its recursion, the contents of the memory variable has
> changed and is now filled with the contents of the called
> recursive procedure rather than the calling one.
>
> Maybe you don't care, maybe your servers have loads of
> memory. Just because its out there and its being used doesn't
> mean it's the most 'efficient'
> thing since sliced bread. You can get into some real pickles
> with recursion.
> Recursion allows for a succinct coding method, but it will be
> a trade off on memory and resources. Recursive procedures can
> be more resource intensive than linear code. Recursive
> procedures are typically harder to debug. With all this
> information I believe recursion is a useful tool, but not
> necessarily efficient.
>
> Your original statement was that a recursive process was 'the
> most efficient' I do not believe that is correct - and you've
> still not convinced me otherwise. 'The process solved the
> problem ergo its efficient' [raspberry noise] ( in a friendly way ;) )
*****************************************************************************
This email and its attachments are confidential and are intended for the above
named recipient only. If this has come to you in error, please notify the
sender immediately and delete this email from your system. You must take no
action based on this, nor must you copy or disclose it or any part of its
contents to any person or organisation. Statements and opinions contained in
this email may not necessarily represent those of Littlewoods Shop Direct Group
Limited or its subsidiaries. Please note that email communications may be
monitored. The registered office of Littlewoods Shop Direct Group Limited is
100 Old Hall Street Liverpool L70 1AB registered number 5059352
*****************************************************************************
This message has been scanned for viruses by BlackSpider MailControl -
www.blackspider.com
********************************************************
This Weeks Sponsor: Cesura, Inc.
Know about Citrix end-user slowdowns before they know.
Know the probable cause, immediately.
Know it all now with this free white paper.
http://www.cesurasolutions.com/landing/WPBCForCitrix.htm?mc=WETBCC
********************************************************
Useful Thin Client Computing Links are available at:
http://thin.net/links.cfm
ThinWiki community - Excellent SBC Search Capabilities!
http://www.thinwiki.com
***********************************************************
For Archives, to Unsubscribe, Subscribe or
set Digest or Vacation mode use the below link:
http://thin.net/citrixlist.cfm
Other related posts:
