[THIN] Re: Home directory and Profile Script
- From: "Braebaum, Neil" <Neil.Braebaum@xxxxxxxxxxxxxxxxx>
- To: <thin@xxxxxxxxxxxxx>
- Date: Thu, 20 Oct 2005 08:52:59 +0100
> -----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.
So - what makes that inefficient, *inherently* compared with any other
approach?
What if that's exactly what's wanted - what if that represents a good
thing?
> 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.
My point was that not every iteration of recursion is left hanging
around - only the currently instantiated ones.
And considering how AD should be structured, there should only be a
handful of iterations concurrently running. Any more than that, and
*any* searches would be wildly inefficient.
Now accepted, recursing *many* times *could* be an inefficient manner of
doing things, but as it stands, recursing a small number of instances,
is probably no more, and quite possibly less resource usage, than your
bloated ADO search.
> 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.
Are you honestly trying to lecture me that doing this by ADO is the most
resource efficient manner?
Look at all the objects you instantiate - and what do you think happens
once you submit your structured query? That it just disappears into some
wondrous, magic cloud, that's the most efficient thing since Babbage's
engine? How many objects, and memory used do you think occurs whilst the
ADO search occurs? What do you imagine is happening at that point?
If you really had any point to make on this WRT efficiency, you'd be
advocating searching the GC as I mentioned earlier.
You know why most *scripters* use ADO searches? Because they don't have
any other method of doing it. When they first had to face using the LDAP
provider, they searched on t'internet for some manner of getting all
users via LDAP, and came across ADO examples, downloaded scripts, and
have copied and pasted ever since, never once thinking about it.
You know why I don't *necessarily* use ADO searches? Because when I
first had to do this, not every client platform could do this, because
it's often a sledgehammer to crack a peanut, and because I can be more
selective and optimum using what I alluded to in my posted example -
passing arguments to the recursive subroutine.
> You can get into some real pickles
> with recursion.
Agreed.
> Recursion allows for a succinct coding method, but it will be
> a trade off on memory and resources.
*Can* be a trade off in memory and resources.
In this example, I highly suspect your ADO search uses more resources
than my lightweight recursive search.
> Recursive procedures can
> be more resource intensive than linear code.
Yes - agreed *can* be.
> Recursive
> procedures are typically harder to debug.
In the examples given, and for somebody relatively new to vbscripting as
the original poster appears, which do you imagine would be easier to
debug?
> With all this
> information I believe recursion is a useful tool, but not
> necessarily efficient.
Agreed, *not necessarily*. It's all about context and alternatives.
> Your original statement was that a recursive process was 'the
> most efficient'
No it wasn't.
My original statement on efficiency was that I find it a more efficient
approach, as *I* can limit the degree of searching, either on depth,
some other condition, or on the starting place.
And given the two code examples given, I stand by my comments that mine
is more 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 ;) )
That's not what I said.
I qualified, previously, why in context, I find my approach more
efficient.
And certainly, the way yours is coded, certainly doesn't make me believe
that efficiency is an aspiration.
If you were truly bothered about efficiency, you'd be searching the GC.
Neil
*****************************************************************************
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:
