asp.net c# speed up of classes

Question

Hi

I work on a big project in company. We collect data which we get via API methods of the CMS.

ex.

DataSet users = CMS.UserHelper.GetLoggedUser(); // returns dataset with users

Now on some pages we need many different data, not just users, also Nodes of the tree of the CMS or specific data of subtreee.

So we thought of write an own "helper class" in which we later can get different data easy.

ex:

MyHelperClass.GetUsers();
MyHelperClass.Objects.GetSingleObject( ID );

Now the problem is our "Helper Class" is really big and now we like to collect different data from the "Helper Class" and write them into a typed dataset . Later we can give a repeater that typed dataset which contains data from different tables. (which even comes from the methods I wrote before via API)

Problem is: It is so slow now, even at loading the page! Does it load or init the whole class??

By the way CMS is Kentico if anyone works with it.

I'm tired. Tried whole night..but it's soooo slow. Please give a look to that architecture. May be you find some crimes which are not allowed :S

I hope we get it work faster. Thank you.

Answer 1

Are you already using Caching and Session state?

The basic idea being to defer as much of the data loading to these storage mediums as possible and not do it on individual page loads. Caching especially can be useful if you only need to get the data once and want to share it between users and over time.

If you are already doing these things, ore cant directly implement them try deferring as much of this data gathering as possible, opting to short-circuit it and not do the loading up front. If the data is only occasionally used this can also save you a lot of time in page loads.

Answer 2

First thing first... Enable Trace for your application and try to optimize Response size, caching and work with some Application and DB Profilers... By just looking at the code I am afraid no one can be able to help you better.

Answer 3

I suggest you try to profile your application and see where the bottlenecks are:

Slow load from the DB?

Slow network traffic?

Slow rendering?

Too much traffic for the client?

The profiling world should be part of almost every senior programmer. It's part of the general toolbox. Learn it, and you'll have the answers yourself.

Cheers!

Answer 4

Bottlenecks usually come in a few forms:

• Slow or flakey network.
• Heavy reading/writing to disk, as disk IO is 1000s of times slower than reading or writing to memory.
• CPU throttle caused by long-running or inefficiently implemented algorithm.

Lots of things could affect this, including your database queries and indexes, the number of people accessing your site, lack of memory on your web server, lots of reflection in your code, just plain slow hardware etc. No one here can tell you why your site is slow, you need to profile it.

---

For what its worth, you asked a question about your API architecture -- from a code point of view, it looks fine. There's nothing wrong with copying fields from one class to another, and the performance penalty incurred by wrapper class casting from object to Guid or bool is likely to be so tiny that its negligible.

Since you asked about performance, its not very clear why you're connecting class architecture to performance. There are really really tiny micro-optimizations you could apply to your classes which may or may not affect performance -- but the four or five nanoseconds you'll gain with those micro-optimizations have already been lost simply by reading this answer. Network latency and DB queries will absolutely dwarf the performance subtleties of your API.

In a comment, you stated "so there is no problem with static classes or a basic mistake of me". Performance-wise, no. From a web-app point of view, probably. In particular, static fields are global and initialized once per AppDomain, not per session -- the variables mCurrentCultureCode and mcurrentSiteName sound session-specific, not global to the AppDomain. I'd double-check those to see your site renders correctly when users with different culture settings access the site at the same time.