Application[] and Session[]

  • Thread starter Thread starter Just D
  • Start date Start date
J

Just D

Hi,

How slowly is to work with these objects - Application[] and Session[] ? Is
it much better to create a huge project or some static library and place all
variables/constants there instead of many Session[] objects?

When I removed some of Session[] objects and replaced by another approaches
I got an illusion that application started working significantly faster? Is
it true?

Did anybody try to evaluate how slow are these objects?

Thanks,
Dmitri
 
Just D said:
Hi,

How slowly is to work with these objects - Application[] and Session[] ? Is
it much better to create a huge project or some static library and place all
variables/constants there instead of many Session[] objects?

When I removed some of Session[] objects and replaced by another approaches
I got an illusion that application started working significantly faster? Is
it true?

Did anybody try to evaluate how slow are these objects?

Thanks,
Dmitri
Click to expand...

What are you storing? Lots of int's for example? Then you get
lots of boxing/unboxing operations. In this case it might be better
to define a class to store a number of int's (that are "natural" to
store together), so ytou can store a reference to that single class.

You can't easily change Session into static variables: Session is
user-specific (or rather "session specific" :-) ), and "static" is
application-wide.

Hans Kesting
 
Hi Hans,

Thank you, I understand why do I need Session[] and Application[]. The
problem is that I'm currently optimizing the application that has been
written before me and later with my participation. The first author used a
lot of variables for everything and I'm trying to move some constants to a
static class and all session-related objects and variables to a huge object,
stored into session[] instead of a few hundreds of Session[] objects. It
makes sense, but I was wondering if anybody tested how slowly is to use
Session[] comparing to other methods, including a separate Class Library
with static members. Just it.

Thanks,
Dmitri

"Hans Kesting"
How slowly is to work with these objects - Application[] and Session[] ?
Is
it much better to create a huge project or some static library and place
all
variables/constants there instead of many Session[] objects?

When I removed some of Session[] objects and replaced by another
approaches
I got an illusion that application started working significantly faster?
Is
it true?

Did anybody try to evaluate how slow are these objects?
Click to expand...
Click to expand...
 
Could you not move the constants to a resource file then load them into a
static class at application start up. Or create a cache source with a
dependency set to an xml file holding your constants?

MattC


Just D said:
Hi Hans,

Thank you, I understand why do I need Session[] and Application[]. The
problem is that I'm currently optimizing the application that has been
written before me and later with my participation. The first author used a
lot of variables for everything and I'm trying to move some constants to a
static class and all session-related objects and variables to a huge object,
stored into session[] instead of a few hundreds of Session[] objects. It
makes sense, but I was wondering if anybody tested how slowly is to use
Session[] comparing to other methods, including a separate Class Library
with static members. Just it.

Thanks,
Dmitri

"Hans Kesting"
How slowly is to work with these objects - Application[] and Session[] ?
Is
it much better to create a huge project or some static library and place
all
variables/constants there instead of many Session[] objects?

When I removed some of Session[] objects and replaced by another
approaches
I got an illusion that application started working significantly faster?
Is
it true?

Did anybody try to evaluate how slow are these objects?
Click to expand...
Click to expand...
What are you storing? Lots of int's for example? Then you get
lots of boxing/unboxing operations. In this case it might be better
to define a class to store a number of int's (that are "natural" to
store together), so ytou can store a reference to that single class.

You can't easily change Session into static variables: Session is
user-specific (or rather "session specific" :-) ), and "static" is
application-wide.
Click to expand...
Click to expand...
 
Just D said:
Hi,

How slowly is to work with these objects - Application[] and Session[] ? Is
it much better to create a huge project or some static library and place all
variables/constants there instead of many Session[] objects?

When I removed some of Session[] objects and replaced by another approaches
I got an illusion that application started working significantly faster? Is
it true?

Did anybody try to evaluate how slow are these objects?
Click to expand...

How many such variables will you be using?

The performance is probably not worth worrying about. My philosophy is to
get the code to work first, then to worry about performance. Of course, this
assumes I don't do something brain-dead to make the performance so bad that
QA refuses to test it!

Also, pay no attention to performance the first time the application starts
after you change the application or web.config. When the application first
starts, everything gets recompiled. You should check performance by running
the same test multiple times and averaging the performance.
 
Back
Top