Dave Anderson said:
Agreed so far.
Hmmm. Let me respond after a bit. But let's first look at how JScript GC is
described in the article you reference:
1. When the script engine is shut down, garbage is collected.
2. When 256 variants, or more than 64KB of strings, or more
than 4096 array slots have been allocated, the garbage
collector sets a flag that says collect soon.
3. Whenever a new statement is executed or the script debugger
starts, that flag is checked, and if it is set, a collection
is done.
If this is true, then I'm not sure step 4 helps much, since GC *still* needs
to be triggered by a new statement (I'm assuming the script debugger is not
being used on the production server, where resources would really be an
issue). Continuing onward...
My point is that step 4 marks the recordsets as available for garbage
collection. It is step 5 that actually triggers the garbage collection.
For example:
rs.Close();
rs = null;
str = "This is a 64K length string...";
Response.Write("Hooray. RS is dead.");
Marks *what* exactly? The variable is still in scope, and has been assigned
a value of null/Nothing. There is nothing in the GC description that
outlines a process for marking something for deletion. I think it's fair to
say that loss of scope does the job, but I'm still unaware of any definitive
MS documentation on the matter. The delete operator is looking more
legitimate by the day.
Here is an except from KB 164494:
When you set the object reference to null, the object is marked as
available for garbage collection, but it is not released until the
garbage collector runs or the script engine is destroyed:
Please show me something from MS that offers the complement -- that WITH
THIS STEP, it *is* marked for deletion. This is exactly the issue I have
been trying to resolve from day 1.
Please see above.
In VBScript, I agree. In JScript, I await proof, or at least a pursuasive
argument. It has to be better than "that's the way it's done in VBScript, so
logic dictates it is the same in JScript".
Please see above.
...and still nothing that describes how an object is MARKED for GC.
Please see above.
The word "disconnected" does not appear in that article. It's a comparison
of GetString(), GetRows(), and iteration. It does, however, say that with
iteration the recordset must remain open through the entire processing and
display cycle. This is incorrect on two measures: (1) there is no display
cycle, and (2) the code need not be structured so inefficiently. Here's an
example that improves on your sub-optimal model:
You neglected to quote the following:
"Specifically, in the pros/cons section of recordset iteration, it
discusses two (2) scenarios that can be acheive by using recordsets that
would be difficult if not impossible to achieve via GetRows/GetString.
This advantage applies equally to disconnected recordset. Disconnected
recordsets also benefit for the fact that they release their associated
connections back into the pool earlier in the processing cycle."
The point I was attempting to make is that recordsets, disconnected or
not, have benefits over GetRows/GetString. In addition to these benefits
which apply to both connected and disconnected recordsets, disconnected
recordset also have the benefit of releasing their connections earlier
than connected recordsets.
Also, to clarify, I intended "display cycle" to mean the phase of
processing that generates output to the Response buffer, which I think
you would agree, certainly exists. If you feel there is a more suitable
term, I would be happy to consider it.
var a = new Array(), RS = CN.Execute(sql)
while (!RS.EOF) {
a.push(
new myObj(
RS.Fields(key1).Item,
RS.Fields(key2).Item,
...
RS.Fields(keyN).Item
)
)
RS.MoveNext()
}
RS.Close()
CN.Close()
a.sort(mySortFunction)
...
...later on:
<A HREF="<%=a
.Prop1%>"><%=a.Prop2%></A> ...
You have offered no proof that this method is more efficient. In
addition the article in question was written in a VBScript environment.
I only cited the article to provide examples where recordsets were
superior to GetRows/GetString, regardless of scripting language. And by
extension, that superioity also applies to disconnected recordsets. In a
JScript environment, there are other factors to be considered to be
sure. Specifically, I would not make such heavy use of the Response
object as it is late bound in JScript. But you already knew that.
Note that by the time the Response Buffer is flushed, the recordset and
connection were long ago closed. Note also that the only bit of "processing
cycle" during which the recordset is open is that bit devoted to building
and reading the recordset.
Using a disconnected recordset, you could have released the connection
object before building and reading the recordset.
I'm not going to dispute that GetRows() is faster than iteration, but I will
point out that your article does not compare JScript performance differences
between them. Is there additional overhead involved in stepping through a
VBArray Object (especially if a sort is in order)? Is it better to keep a
VBArray Object in scope than a Recordset Object? Give me a few days, and
I'll run a test on it, then perhaps offer an article to Aaron.
I stated previously and at the beginning of the article, the scripting
langauge was VBScript. I would certainly appreciate your sharing any
findings of a similar analysis in a JScript environment. I am sure Aaron
would appreciate it as well.
I would like to know if that is indeed true. It is almost certainly true
that closing the connection improves pooling performance.
I guess the only way to find out would be to test it or take my word for
it. I recommend testing it.
I was, but only jokingly. JScript is way too cool to use anything else for
routine ASP tasks.
Disaster averted.
Great, I feel like progress is being made.
-Chris