"Michael D. Kersey" <md******@hal-pc.org> wrote in message
news:ug**************@TK2MSFTNGP10.phx.gbl...
: BTW why use the Scripting.Dictionary object when you have Session and
: Application variables available?
Because you might run into scoping issues. Session/Application objects are
global, and there is no way to make them "local" (or reduce their scope in
any way).
If I use a Script.Dictionary component, then I can limit the scope of that
component (eg to just a routine, or a page). I do not need to worry about
accidently over-writing some value on another page, or in another routine.
Also, I'm wary of adding lots of unnecessary stuff to Session or Application
objects. That makes your app unportable. I have plenty of applications that
I've having issues porting to .NET (or adding new features using .NET)
because of excessive overuse of Session variables, which makes it difficult
to run part of the app using ASP, and part using ASP.NET
Cheers
Ken
"Michael D. Kersey" <md******@hal-pc.org> wrote in message
news:ug**************@TK2MSFTNGP10.phx.gbl...
: Ken Schaefer wrote:
: > Are you adding a lot of key/value pairs? Or adding a lot of data for a
few
: > pairs?
: >
: > I also use Scripting.Dictionary in several Classic ASP applications
(mostly
: > for holding a list of potential user errors, and then accessing them
when
: > producing "error summary" for the user), both on Windows 2000 and
Windows
: > 2003, and have noticed no perceptable difference. However, I'm not
adding
: > much data (just a short error message), though potentially might add
25-30
: > key/value pairs.
: >
: > Cheers
: > Ken
: >
: > "Rodd Snook" <us****@nospam.snookums.port5.com> wrote in message
: > news:pa****************************@nospam.snookum s.port5.com...
: > : I have an application which makes extensive use of the
: > : Scripting.Dictionary object. I'm not doing anything silly like putting
: > : them outside the page scope -- just creating quite a few of them and
: > : stuffing quite a lot of data (from and MS SQL database) into them.
: > :
: > : On Windows 2000 server, everything is fine. If the data structures get
: > : really big it slows down, but for normal operation it's no problem.
: > :
: > : Recently our hosting provider moved to Windows Server 2003, and
everything
: > : went to the dogs. Pages that used to load in 2-3 seconds can now take
in
: > : excess of 30 seconds to load. I've done extensive profiling, and it
seems
: > : that the dictionary is to blame. Specifically, putting data into them.
: > : Creating them is fine, getting results from the database is fine,
adding
: > : the key/value pairs is a nightmare.
: > :
: > : The extreme difference in performance makes me think that the server
is
: > : out of memory and thrashing, but the provider insists that there is
: > : plenty of free memory, and that my application is the only one with a
: > : problem. Maybe I'm wrong, and it's a data marshalling issue, not a
memory
: > : allocation issue.
: > :
: > : The paranoid side of me says that ASP is intentionally "unoptimised"
in
: > : 2003 to "encourage" people to move to .NET.
: > :
: > : Has anyone else seen this, or have any ideas what causes it?
: > :
: > : Rodd
: Scripting.Dictionary object had (has?) some threading issues; Eric
: Lippert of Microsoft wrote it while learning about threading:
:
http://blogs.msdn.com/ericlippert/ar.../19/53054.aspx
:
: There he talks about problems that can occur when using that object.
:
: Possible cures:
: There is a component, called "Lookup Table object", written by Microsoft
: programmers who wanted better performance than the Dictionary object
: provided. Perhaps you could use it.
:
: BTW why use the Scripting.Dictionary object when you have Session and
: Application variables available?
:
: Good Luck,
: Michael D. Kersey
