[THIN] Re: Home directory and Profile Script
- From: "Lilley, Brian" <brian.lilley@xxxxxxxx>
- To: "'thin@xxxxxxxxxxxxx'" <thin@xxxxxxxxxxxxx>
- Date: Wed, 19 Oct 2005 18:01:49 +0100
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 ;) )
-----Original Message-----
From: thin-bounce@xxxxxxxxxxxxx [mailto:thin-bounce@xxxxxxxxxxxxx] On Behalf
Of Braebaum, Neil
Sent: 19 October 2005 15:12
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 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 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
==============================================================================
Please access the attached hyperlink for an important electronic communications
disclaimer:
http://www.csfb.com/legal_terms/disclaimer_external_email.shtml
==============================================================================
********************************************************
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:
