Classes Vs Modules

[samsmithnz]

I only want to talk about SPEED here, not what some of you (and I of course) perceive as 'good' programming practice.

 

I'm 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).

 

I'll 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.

 

I'd usually go straight ahead and do this, but I'm really worried about performance, so that's why I'm trying to consider it here, at the expense 'good' programming practice. What is faster? I'm currently thinking that leaving it where it is should be slightly faster......

[PlausiblyDamp]

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.

[samsmithnz]

well like I said, I'm NOT concerned with OO principles at all in this instance, and I can really do without that overhead in this specific instance.

[PlausiblyDamp]

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.

[samsmithnz]

OK you've got my attention. How do I use a 'shared member', and why is so much faster than a normal class?

 

Why wouldn't I jsut use this all the time?

[PlausiblyDamp]

A normal class needds to go through the instantiation process every time it's used and contains instance specific information.

 

i.e.

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.

 

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)

[samsmithnz]

thanks PlausiblyDamp, thats useful. Dot NET is still surprising me on a regular basis.

[Derek Stone]

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.

[Nerseus]

I wonder what kind of architecture you're designing that you must call a webservice on every keystroke? If speed is in mind, this doesn't 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 wouldn't 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

[samsmithnz]

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. I'm developing this for an intranet application, so bandwidth or latency really aren't issues.

 

Check out the document I've attached, it's an article I started to write, but I can't ever finish, due to legal reasons. I'm allowed to talk about it here, and I'm happy to answer further questions.

client side web services.zip

[mocella]

If it's an Intranet app, you could probably do some remoting, which should be faster than a webservice, but I don't know your requirements or environment.

 

If performance is your primary concern here, check out this article and make your own interpretations, but generally speaking, binary is going to be faster than passing text(XML):

 

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/bdadotnetarch14.asp

[samsmithnz]

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+.

[mocella]

If speed is your goal, I'd seriously consider remoting over a web-service.

 

The downside is you've 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.

[samsmithnz]

We are still prototyping, although we are near the end, as the current solution has surprised us all with its speed.

 

I've downloaded/printed the article you linked to above and I'm working through it. Do you have any code samples for remoting via an asp.net page? Preferably from the clientside so that the page doesn't postback everytime you type...???

[mocella]

Unfortunatley, I haven't done anything quite like that - I've 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 you'd use for your web-service, just replace your web-service calls with the remoting calls.

[Nerseus]

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, it's got a lot of data entry. Or, once a user gets it they'll 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 it's a medical procedure code and they know it starts with 19 but can't remember if it's 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 they're keyboard-centric as most data entry end-users are. I'd make sure you're developing prototypes that some end-users or super-users can test before you get too far into prototyping.

 

-Nerseus

[samsmithnz]

I'm 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 you're looking at this and thinking it could never work, but if you saw it working you'd 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 :)

[Nerseus]

Don't discount cacheing as an alternative, by the way. I don't 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 won't 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 you're 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 they're 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.

 

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

 

-Nerseus

[samsmithnz]

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!!!