[THIN] Re: Home directory and Profile Script
- From: "Andrew Wood" <andrew.wood@xxxxxxxxxxxxxxxx>
- To: <thin@xxxxxxxxxxxxx>
- Date: Wed, 19 Oct 2005 14:46:02 +0100
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/%3C4084c2e3@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. It uses a
inefficient programming method to do its function. 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.
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.
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. 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.
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. The guy who asked the question has
probably used Rick's code and has gone home.
We can develop this further off list by all means as I'm sure people have
got bored by now.
And a smilie at the end, because we're not bickering :)
-----Original Message-----
From: thin-bounce@xxxxxxxxxxxxx [mailto:thin-bounce@xxxxxxxxxxxxx] On Behalf
Of Braebaum, Neil
Sent: 19 October 2005 13:43
To: thin@xxxxxxxxxxxxx
Subject: [THIN] Re: Home directory and Profile Script
Andrew
You can keep bickering about this if you like - perhaps due to the affront
of having an alternative suggested to your example.
But you simply stating something like that, won't make it true. There are
some semantic differences about where various things are being processed.
Ignoring that, your repeated, yet unfounded assertions about efficiency are
misplaced.
Every time I ask you about what you automatically assume is more efficient
about how ADO searches *WILL* be performed, you uncannily duck the question.
When I've mentioned about having to deal with paged enquiries, you let it
slide.
So if you want to bicker endlessly about why you think your answer is the
pinnacle of efficiency, and mine is the devil's work - then by all means, up
your game. Otherwise, you are simple coming across as churlish about a
postulated alternative.
The ironic thing - when Rick posted a more simplistic alternative to my
suggestion - I welcomed it as the good form it was.
Neil
> -----Original Message-----
> From: thin-bounce@xxxxxxxxxxxxx
> [mailto:thin-bounce@xxxxxxxxxxxxx] On Behalf Of Andrew Wood
> Sent: 19 October 2005 13:33
> To: thin@xxxxxxxxxxxxx
> Subject: [THIN] Re: Home directory and Profile Script
>
> It is, and you know it.
>
> -----Original Message-----
> From: thin-bounce@xxxxxxxxxxxxx
> [mailto:thin-bounce@xxxxxxxxxxxxx] On Behalf Of Braebaum, Neil
> Sent: 19 October 2005 13:25
> 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 13:18
> > To: thin@xxxxxxxxxxxxx
> > Subject: [THIN] Re: Home directory and Profile Script
> >
> > So what you're saying is - 'yes, my process was inefficient but
> > there's more than one way to skin a cat'. I concur.
>
> No - I'm not saying my process is inefficient.
>
> *Think* about what will really happen when an ADO search is
> kicked-off, think about what I'm coding, then tell me it's leagues
> apart in terms of efficiency?
>
> > Just think about how a recursive procedure works; write it out on a
> > bit of paper and tell me that any one time you only have one set of
> > variables.
>
> 1. We're talking about objects.
> 2. They're destroyed every time the sub ends.
>
> > There's no need for a whitepaper - just a yes or no would do ;)
>
> It's a pointless question.
>
> Garbage collection occurs, we're talking about objects that are
> transient.
>
> You seem to be under the mistaken impression that everything done by
> ADO is as efficient as it gets, and doing similar, but perhaps more
> selective things *easier* and by hand must be inefficient. Now there's
> a point about where the processing may occur - but having to contend
> with paging for larger enquiries is telling you something, isn't it?
>
> 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:
