Classes Vs Modules

samsmithnz

samsmithnz

Well-known member
Joined
Jul 22, 2003
Messages
1,038
Location
Boston
I only want to talk about SPEED here, not what some of you (and I of course) perceive as good programming practice.

Im trying to get the BEST performance out of a webservice. The webservice can be called from one client up to 4 or 5 times a second (depending on how fast you can type).

Ill give you a quick background on how this works, so that you understand why it has to be this way. I have a ASP.NET webpage where the user types in a user name. As they type, the text is passed through a web service (using client side javascript), which extracts the information in a SQL Database (using a sp and a like %). This data is then converted into HTML and returned to the client to display in a client side popup menu thingy.

The question I have here is this:

The HTML conversion function is currently sitting in the main webservice asmx file. I was wondering if it wouild be quicker to leave it there or to move it into a class, and create instances of the class everytime I need it.

Id usually go straight ahead and do this, but Im really worried about performance, so thats why Im trying to consider it here, at the expense good programming practice. What is faster? Im currently thinking that leaving it where it is should be slightly faster......
 
Creating class instances each time you need to use this function will incur overheads (creating, memory and sooner or later garbage collection), but will be more re-usable. Have you considered a class with a Shared (or static if using C#) method - behaves more like a VB module but is still following OO principles.
 
well like I said, Im NOT concerned with OO principles at all in this instance, and I can really do without that overhead in this specific instance.
 
Doing it with shared members would give you both the speed of using a module as well as maintaining OO principles - feel free to go out of your way to not use OO though.
 
OK youve got my attention. How do I use a shared member, and why is so much faster than a normal class?

Why wouldnt I jsut use this all the time?
 
A normal class needds to go through the instantiation process every time its used and contains instance specific information.

i.e.
Code: 
public class MyClass
 
private FirstName as string
private LastName as string

public sub SetFirstName(x as string)
FirstName = x
End sub

public sub SetLastName(x as string)
LastName = x
End sub

public function GetName as string
return FirstName & " " & LastName
end function

etc.
end class

example of using it

causes instantiation etc
dim x as new MyClass    

multiple calls often used when dealing with class
x.SetFirstName("Blah")
x.SetLastName("Smith")
Label1.Text = x.GetName()

class memory released  sometime later

which is fine if a class needs to remember information between calls and behave in a stateful way. (Often the case in a windows app, or if the object is being stored in a Session for example)

if you simply want to make a module like function call and avoid the state management etc. then something like the following would work.

Code: 
public class MyClass

note no private vars etc.

shared function
public Shared function FullName (fName as string, lName as string)  as string
return fName & " " & lName
end function

end class

usage
Label1.Text = MyClass.FullName ("Blah","Smith")    never instantiated etc.

each however have their own strengths and weaknesses - but they can be combined in a single class.
This is used a lot throughout the .Net framework (Math.Sqrt - Math is the class, MessageBox.Show - MessageBox is the class)
 
A module is considered by the VB.NET compiler as a static sealed class. So whether or not you create a module the assembly will wind up with a class in it anyway.
 
I wonder what kind of architecture youre designing that you must call a webservice on every keystroke? If speed is in mind, this doesnt sound like a good place to start :)

Is this a type-as-you-go combo of sorts, to dynamically filter? There are better approaches than calling a webservice on every keystroke. Why not wait for a pause (a half second or more) and then call the webservice - give the user a chance to type 2 or 3 letters (or more). WebServices are going to be slow - slow enough that I wouldnt count on a single user getting in/out 4 or 5 times a second. Not unless you have a no more than a few users per website.

-nerseus
 
Its not as bad as it sounds. When you first hear about it, you say "no way will that be fast". But it is. Infact I can type as fast as I can and it will work, even with a 100ms latency. Is this for everyone? No. Im developing this for an intranet application, so bandwidth or latency really arent issues.

Check out the document Ive attached, its an article I started to write, but I cant ever finish, due to legal reasons. Im allowed to talk about it here, and Im happy to answer further questions.
 

Attachments

All we are trying to do is display a popup menu that shows a filtered list as the user types in a textbox. This, unfortunetly is a requirement, as there are so many possible values to select.

Our environment is all IE6, win 2k+.
 
If speed is your goal, Id seriously consider remoting over a web-service.

The downside is youve probably already got your code in place, etc, but the upside is that a little work now may pay off as increased performance, which is what you seem to be after anyhow.
 
We are still prototyping, although we are near the end, as the current solution has surprised us all with its speed.

Ive downloaded/printed the article you linked to above and Im working through it. Do you have any code samples for remoting via an asp.net page? Preferably from the clientside so that the page doesnt postback everytime you type...???
 
Unfortunatley, I havent done anything quite like that - Ive been doing smart-client/WinForms development most of the past 2 years.

I imagine the same kind of logic applies to using the remoting object as youd use for your web-service, just replace your web-service calls with the remoting calls.
 
Remoting should be very similar to webservices - just limited to an intranet. It might be ideal for your situation.

Do I get points for guessing what you were doing (dynamic filtering of a combo)? :)

If your app is like most others, its got a lot of data entry. Or, once a user gets it theyll mostly be using the keyboard. It can sometimes be hard tell users that what they think they want("I want this combo to show me ALL 10,000 values!"), is different from what they really want. For example, 9 out of 10 times a real end-user will tell you that they want to type in a code, not select it from a list. Maybe its a medical procedure code and they know it starts with 19 but cant remember if its 191a or 192c or something close. With that in mind, a custom solution often works great. Two common solutions come to mind:
1. Only fill the combo after at least X number of chars are typed. Once a combo gets 2 chars, run your search and fill the combo. Normally, knowing the first two chars of a lookup table will get you to no more than 100 rows. If they delete a character (back to 1), remove the items and wait for the next char again.

2. Put a timer on the change event. After 200ms (or whatever a user deems appropriate), run a search. With webservices, you could even start the search asyncronously on each change event and fill it when the query was done.

But running a query on every keypress is going to have some users annoyed, more if theyre keyboard-centric as most data entry end-users are. Id make sure youre developing prototypes that some end-users or super-users can test before you get too far into prototyping.

-Nerseus
 
Im in Boston, and we will actually have users in our offices in Sydney, Asia, and Europe using the application, but they all have T1 connections, and testing has shown performance is ok. I know youre looking at this and thinking it could never work, but if you saw it working youd be surprised. Really surprised.

But your sugguestions are still good ones and I may implement some of them anyway, you can never make something too fast :)
 
Dont discount cacheing as an alternative, by the way. I dont know how big your tables are or how often they change, but you might be able to get a scheme in place for downloading lookups.

For my current project (or set of projects), we utilize client side cacheing for a LOT of things - mostly lookups. For 99% of the lookups we have, they definitely wont be changing very frequently - every few weeks at the most, most just once a year. I pull them down locally and keep them in memory. Even filtered lookups like youre implementing can be done pretty easily. On every keypress (or after 2+ or on a timer, as above), check some local cache for the values. If theyre not there, get them and cache them. For example, use a static hashtable variable to keep all the lookups, the key could be the first letter of the lookup - when the user types the first letter, get those lookups and cache them. As they type more letters, just filter the local DataTable.

Dont rush to dismiss cacheing because they "wont be as dynamic as getting them each time". That argument only makes sense if they might actually be changing pretty often.

-Nerseus
 
Does caching involve a postback though?

the problem here is that I need to get employee names (3000+), case codes (5000+) and client info (1000+), and all of these can change at any time (IE if a user inserts one, they have to see it right away.)

there are alot of things in this project that make it difficult, but we have to live with them. All of our users seem more concerned with these filtered lists than the actual application!!!
 
Back
Top