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"
[quoted text, click to view] >> 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.
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 [quoted text, click to view] 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
[quoted text, click to view] "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
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
[quoted text, click to view] "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.
>
[quoted text, click to view] "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
Don't see what you're looking for? Try a search.
