[THIN] Re: Home directory and Profile Script
- From: "Braebaum, Neil" <Neil.Braebaum@xxxxxxxxxxxxxxxxx>
- To: <thin@xxxxxxxxxxxxx>
- Date: Wed, 19 Oct 2005 15:11:53 +0100
> -----Original Message-----
> From: thin-bounce@xxxxxxxxxxxxx
> [mailto:thin-bounce@xxxxxxxxxxxxx] On Behalf Of Andrew Wood
> Sent: 19 October 2005 14:46
> To: thin@xxxxxxxxxxxxx
> Subject: [THIN] Re: Home directory and Profile Script
>
> I'm not bickering - there may be some petty quarrelling but
> its hardly bad tempered. We have a minor dispute at best.
> Quote me a bicker. In 2 lines or less.
>
> Now I'll quote
> (http://news.povray.org/povray.tools.general/thread/%3C4084c2e
> 3@xxxxxxxxxxxx
> org%3E/?ttop=218560&toff=50)
>
> 'Recursive function calls are a burden in practically all
> programming languages because they have quite a lot of
> overhead (the exception being the tail recursion optimization
> in some languages when the recursive call is made properly).
> Recursion is usually also considerably slower than doing it
> iteratively.'
>
> My original point was that I thought your 'efficient' process
> inefficient. I thought this as it does a number of
> unnecessary actions.
Such as?
What is it you think it's doing unnecessarily that won't be done by
anything else that has to search AD and come up with matches?!
There are some types of container objects that I'm never even querying!
And certainly a whole raft of objects I'm never touching.
> It uses a inefficient programming method
> to do its function.
There's nothing - and I repeat *NOTHING* inefficient about recursion.
Anybody can post comments on a web page, doesn't necessarily make them
authoritative.
How much recursive / re-entrant code do you think is out there - then
ask yourself *why* it's out there.
> I based my question largely on the fact
> that you incorporated a recursive procedure - which can be a
> neat way of reducing code length, but an inefficient method
> of getting the job done.
Rubbish.
Given the choice - in this instance - of doing it iteratively, or doing
it recursively, *what* would be more efficient. The potential that there
may be transiently more resources used? Is that it?
The only reason recursion is being used, here, is that the logic is
apply identically to specific sub-objects, when qualified with
additional pathing information. How would - in this example - attempting
to do this search iteratively be notably any more efficient?
> Yes, it does remove all the memory variables at the end. But
> during the process, while it goes through in an iterative
> process each time you call the process again another set of
> variables is created and kept on the heap.
And?
Do they just, like, stay hanging around until everything finishes? Are
you actually thinking about how the subroutine will be used, and ended?
> I'd grant you, sites with big user lists would experience
> difficulties searching their entire user space with my query
> method for this particular query set. While the example you
> gave would circumvent this by doing lots of little queries. I
> don't think that's an efficiency saving. It simply works,
> inefficiently, to get round a limitation.
Nonsense.
*What* is it you keep asserting is inefficient? Recursion?
The same code is being re-used, and the details from each run, are being
used to descend. If you have a very deep hierarchy - you *may* have
possibly 3, 4, 5, maybe slightly more objects instantiated at any one
point. Compare that to how many you *have* to instantiate in order to
use ADO for the life of the search.
> I think for many
> AD's a recursive procedure would be inefficient and would be
> better replaced by a well formed query - following guidelines
> shown here
> http://msdn.microsoft.com/library/default.asp?url=/library/en-
> us/adsi/adsi/w
> hat_makes_a_fast_query.asp.
And would you like to cite any of that criteria, that I'm breaking?
> I didn't think my procedure was great - I said this in the
> original post. I based that opinion on the fact that I'd
> written a script that looked for stuff I didn't need: which
> is inefficient. I think the example Rick gave was much
> neater and would advocate it in preference, because it doesn't.
>
> Now, you've written a lot, quite a lot in fact, on this topic
> - none of which answered my original question 'how is your
> processes more efficient'.
> I don't think it is - I stand by that.
That's your choice.
But merely asserting it, won't make it so. You've tried to suggest some
things, aspects of the way it works, that somehow support your
contention, but you've merely glossed over some vague, wafty statements
as if it somehow supports your assertion. But if doesn't.
And in the end, it's more tricky and complex to code, and look at all
the attributes you were dragging out - and you accuse me of
inefficiencies.
In terms of efficiency, there's probably nothing much between the two
approaches - they will both probably traverse the entire directory, and
will be selective about what types of object they return, using filters.
The reason why I said I find it more efficient, being I can decide
whether to be selective - I can decide how many levels I want to go
down, if I want. I can easily decide to omit certain branches, or
certain objects.
> The guy who asked the
> question has probably used Rick's code and has gone home.
Most likely.
> We can develop this further off list by all means as I'm sure
> people have got bored by now.
S'reasonably on-topic.
At the moment, you're not developing the discussion. You're invalidly
asserting something, and scrabbling around (and failing) to try and come
up with something to support your claims.
Of course, all in the best possible mutual friendliness ;-)
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:
