Application[] and Session[]

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

Nov 18 '05 #1

Hans Kesting

"Just D" <no@spam.please> wrote in message news:mCuCc.2229$CR3.1510@lakeread03...

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

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

Nov 18 '05 #2

Just D

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?

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.

Nov 18 '05 #3

MattC

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" <no@spam.please> wrote in message
news:aDwCc.2233$CR3.1346@lakeread03...

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?

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.

Nov 18 '05 #4

Scott Allen

Hi Dimitri:

It's a relative answer that depends on how many objects, the type of
the objects, and where you keep session state (in memory, shared
server, or SQL Server). The Application object can easily be avoided,
Session is not so easy. Do some refactoring and then test to see if
your performance has improved.

I have some other thoughts typed up in these articles:

http://www.odetocode.com/Articles/83.aspx
http://odetocode.com/Articles/89.aspx

HTH!

--
Scott
http://www.OdeToCode.com
On Wed, 23 Jun 2004 23:35:06 -0700, "Just D" <no@spam.please> wrote:

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

Nov 18 '05 #5

John Saunders

"Just D" <no@spam.please> wrote in message
news:mCuCc.2229$CR3.1510@lakeread03...

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?

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.

--
John Saunders
johnwsaundersiii at hotmail

Nov 18 '05 #6

John Saunders

"Just D" <no@spam.please> wrote in message
news:mCuCc.2229$CR3.1510@lakeread03...

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?

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.

--
John Saunders
johnwsaundersiii at hotmail

Nov 18 '05 #7