[THIN] Re: Home directory and Profile Script
- From: "Joe Shonk" <joe.shonk@xxxxxxxxx>
- To: <thin@xxxxxxxxxxxxx>
- Date: Thu, 20 Oct 2005 13:46:26 -0700
If I may, the whole point of the script is to extract the TS Profile Path
for all users in AD. Correct? Is it really worth trying to optimize the
code and resources used? Especially when a script like this is used once
every full moon? Shouldn't the goal be to get the job done? So it takes a
few extra seconds to process or an extra megabyte of RAM on your PC doing
one way vs. the other. Most people use the ADO method because that's what
Microsoft has posted on the script site. A simple cut and paste, change a
few parameters and you're up and running... Granted, shifting the workload
from your workstation to the DC isn't the best idea.
Using a recursive routine is not going to kill anything. It's quite
effective when sorting through hierarchical data. The amount memory used
going to be first incursion variables plus the variables for each recursion.
The total memory used at a given time may actually be less that a single
filtered query as ALL of the filtered objects will be returned in one large
array. The disadvantage of using a recursive routine is that you will
perform a query for each recursion.
Now on the flip side... Recursive routines are difficult to troubleshoot and
understand... Sure, it's easy for me understand and I use them from time to
time, but it's not so easy for most people out there. (These are admins,
not programmers... Remember, they are working on Microsoft products, not
Linux) Sure it's cute to do things like use foo and bar for variables, but
do it for yourself... If you're writing the code for a customer, write it so
that they can understand and support it.
Efficiency is more than just how much memory or CPU is utilized or even how
short the code it. It also includes readability and supportability (if
that's a word)
Joe
-----Original Message-----
From: thin-bounce@xxxxxxxxxxxxx [mailto:thin-bounce@xxxxxxxxxxxxx] On Behalf
Of Braebaum, Neil
Sent: Thursday, October 20, 2005 12:53 AM
To: thin@xxxxxxxxxxxxx
Subject: [THIN] Re: Home directory and Profile Script
> -----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=TBCC
********************************************************
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
********************************************************
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:
