i have PIII sytem with 256MB RAM. but my a simple application (only a form) is runnuing to slow. and in other machine also.
the form is containing a treeview and a tab control with some textboxs...
why?
anand
Printable View
i have PIII sytem with 256MB RAM. but my a simple application (only a form) is runnuing to slow. and in other machine also.
the form is containing a treeview and a tab control with some textboxs...
why?
anand
VB.NET isn't slow at all (I'm currently developing a shoot'em up game with it, and I couldn't be more impressed with its efficiency. Much better than VB6).Quote:
Originally posted by Anand_thakur
i have PIII sytem with 256MB RAM. but my a simple application (only a form) is runnuing to slow. and in other machine also.
the form is containing a treeview and a tab control with some textboxs...
why?
anand
Could you further describe your problem? Is it just in the IDE that you're experiencing slow down? Is it just when you load the program?
after build the application...
whenever i run my application...the forms appearance is to slow...first the form will appear then the controls appears one- by one....
same things is happaning when i run the exe of that application.
anand
Have you tried single stepping through your code (using the F8 key)?
Sometimes applications run slow because there are control-generated events firing that you hadn't intended. Single stepping should highlight what is going on.
I had to develop on a PIII 256Mb, and while VS.NET ran very slowly the apps I generated ran ok. Agree with the other reply, try a spot of debugging.
It's true that VB.NET is slower than VB6 because especially when running the application first time. Unlike in VB6, .NET's exe is not transformed to assembly at the beginning. Thru MSIL, it often generates native code on the fly depending on the applcation's requirement.
VB6(IDE & execution) is faster than VS.NET2002 and VS.NET2003 (as I've heard) is faster than VS.NET2002 .
Just a quick addition
try the ngen.exe utility to generate native (not MSIL) code, might be able to squeeze a few extra miles per hour out of your app.
PS make sure you set the complier option to BUILD and not DEBUG
There is no way VB6 is faster than .NET! I never got the speed I currently have in my games with VB6! Am I the only one to have experienced this? (Though I agree that the IDE is a bit slower in .NET)
i have only my experience to go on but i have to agree with the above. Differences only really show on big apps i feel . The VS7 IDE can grind a bit though, but it really is a small price to pay and i still feel it outruns JBuilder/Forte and the likeQuote:
There is no way VB6 is faster than .NET!
I wouldn't go so far as to say VB.NET is slow...granted it isn't as intelligent as other programming languages, but it isn't retarded either...:D
Oh wait, my mistake...you meant speed wise...hehe..how embarassing...
I develop on Win2K, PIII 850, with 256RAM...I haven't experienced any problems...are you running other applications at the same time? what about your system processes? check to see how much memory is being used when you start one of your apps.
What's the OS you are running ? How much mem ? :DQuote:
Originally posted by Hu Flung Dung
There is no way VB6 is faster than .NET! I never got the speed I currently have in my games with VB6! Am I the only one to have experienced this? (Though I agree that the IDE is a bit slower in .NET)
Well, I guess I do have a better system than Anand,Quote:
Originally posted by Pirate
What's the OS you are running ? How much mem ? :D
WinXP pro, P4 1.4, 256 PC-800
But, at least on my sys, VB.NET apps are quite a bit faster than roughly equivalent VB6 apps, though i never ran any "true" benchmarks to officially test it.
Mine is better yours :DQuote:
Originally posted by Hu Flung Dung
Well, I guess I do have a better system than Anand,
WinXP pro, P4 1.4, 256 PC-800
But, at least on my sys, VB.NET apps are quite a bit faster than roughly equivalent VB6 apps, though i never ran any "true" benchmarks to officially test it.
WinXP Pro , P4 2.4 , 750 DDR , Gforce4 64DDR .
It runs VS.NET faster than my old machine but not after I applied some ****ing SP.
VB.NET isn't slower than VB6 at all... It's only an impression. As someone else already said, the code is compiled into native code on the fly, but ONLY ONE TIME, and ONLY WHEN NEEDED. So If you have Two forms, the main form with a button (that will make the secondary form shows) and a secondary form, your application will start slowly (because the framework compiles this form). When you push your button, the first time, and only the first time, your secondary form will show slowly, because the framework compiles it, but when you close it, and push again your button the form will show immediately because the code is already compiled!
You have a beautiful development tool, which can make programmers life easier! You can write code in COBOL, FORTRAN, Pascal, C, C++, C#.... and access ALL these object within VB.NET!!! Marvellous thing... And VB.NET is very fast! If you write a code snippet in VB and test its performance, port it to C++ (without code adjustment obviously), you'll notice no difference in speed!!!
I beg to differ, Xmas79. I've written functions in both VB.NET, VB6, and C++ to replace SQL comments with spaces (for parsing SQL code). The C++ version is at least an order of magnitude faster; currently I am trying to see how I can speed the VB.NET code up, but I'm not having much luck.
Have you tried VS.NET 2003 ? It's much more faster than the old version . Seems a lot of bugs were fixed down . :D
Yes, VB.NET 2003.
If you'd like a challenge, see how fast you can write a function that replaces SQL comments with spaces. The C++ version blows the VB6 and VB.NET 2003 versions out of the water, but maybe I'm missing something.
You have line comments (--) and block comments (/**/), but they don't affect commenting if they are inside strings (''). A "/*" after a "--" on the same line does not start a block comment. A "*/" always stops a block comment, even after a "--" on the same line.
VictorB212:
This can be due to the precompiled routines, e.g. "strcmp(s1,s2)" can be faster (much) than the VB.NET version (dont remember the method name in the string class in this moment) (and I really don't think so, because these two functions, as they do the same thing, will be compiled in the same IL, so only one version of this function is needed).
What I mean is if you write code, code and code, (what can you do without precompiled functions???Everything... :D I hope :confused: ) there's no difference.
Another thing: did you write code in C++ (from VS6) or C++.NET? Remember the ".NET framework" is still present in VB.NET, never in C++, and it seems to me that it can be disabled putting the "unsafe" word in the function headers of the C++.NET (or this is C#? Boh...)
Actually, those vb functions aren't precompiled as you say. They just call the .NET equivalent in the String class (or StringBuilder class). Due to the extra overhead though, using strcmp would be slower (much) than calling its .NET equivalent directly!Quote:
Originally posted by Xmas79
VictorB212:
This can be due to the precompiled routines, e.g. "strcmp(s1,s2)" can be faster (much) than the VB.NET version (dont remember the method name in the string class in this moment) (and I really don't think so, because these two functions, as they do the same thing, will be compiled in the same IL, so only one version of this function is needed).
What I mean is if you write code, code and code, (what can you do without precompiled functions???Everything... :D I hope :confused: ) there's no difference.
Undoubtedly, the C++ code will be faster.... it seems to me the .Net runtimes are pretty much wrappers for native code...
For a true fair comparison though, you would have to precompile the .Net code, and use Stringbuilder and other strictly .NET functions (for instance no mid$() or Left$() )....
In the end, the difference shouldn't be appreciable... but I would bet the C++ code would still win out, and that's ok. The point is to be able to code programs without worrying about all the crap that C++ drags with it... memory leaks... poor standardization...etc...
Now, you could write the same function in Assembly... but when you need to make changes to how that function behaves... well, a C# project would be hella easier to update... and that's the idea...
btw Victor, post your code... I would like to see what functions you were using...
Here's the code. It replaces what would be ANSI SQL comments with spaces.VB Code:
Private Function DeleteComments(ByVal s As String) As String 'Replaces comments in the SQL code with spaces 'Comments consist of --comment and /*comment*/ Dim iChar As Integer Dim bBlockComment As Boolean Dim bLineComment As Boolean Dim bQuote As Boolean Dim c() As Char Dim cCur As Char Dim cNext As Char c = CType(s, Char()) For iChar = 0 To c.Length - 1 cCur = c(iChar) If cCur = vbCr Then bLineComment = False If bBlockComment Then c(iChar) = " "c End If Else If iChar < c.Length - 1 Then cNext = c(iChar + 1) Else cNext = " "c End If 'if the current character is not commented out, then check to see if 'it is the begin/end of a quote If Not (bLineComment OrElse bBlockComment) AndAlso cCur = "'"c Then bQuote = Not bQuote ElseIf Not bQuote Then 'comment status can be toggled if the current character is not in a quote If Not (bLineComment OrElse bBlockComment) AndAlso cCur = "-"c AndAlso cNext = "-" Then bLineComment = True c(iChar) = " "c iChar += 1 c(iChar) = " "c ElseIf Not bLineComment AndAlso cCur = "/"c AndAlso cNext = "*"c Then bBlockComment = True c(iChar) = " "c iChar += 1 c(iChar) = " "c ElseIf bBlockComment AndAlso cCur = "*"c AndAlso cNext = "/"c Then bBlockComment = False c(iChar) = " "c iChar += 1 c(iChar) = " "c ElseIf bLineComment OrElse bBlockComment Then c(iChar) = " "c End If End If End If Next iChar Return CStr(c) End FunctionI've gotten the VB.NET code to run at about 385ms per MB; the C++ runs at about 241ms per MB.PHP Code:void DeleteComments(char* cSrc)
{
bool bBlockComment = false,
bLineComment = false,
bQuote = false;
char* c;
// iterate through all the characters
for (c = cSrc; *c != NULL; ++c) {
if (*c == '\xD') { // this character literal should start with a backslash
// we have a carriage return
bLineComment = false;
if (bBlockComment)
*c = ' ';
continue;
} else if (!(bLineComment || bBlockComment) && *c == '\\'') { // this character literal should also start with a backslash
bQuote = !bQuote;
} else if (!bQuote) {
if (!(bLineComment || bBlockComment) && strncmp(c, "--", 2) == 0) {
bLineComment = true;
*c = ' ';
++c;
*c = ' ';
} else if (!bLineComment && strncmp(c, "/*", 2) == 0) {
bBlockComment = true;
*c = ' ';
++c;
*c = ' ';
} else if (bBlockComment && strncmp(c, "*/", 2) == 0) {
bBlockComment = false;
*c = ' ';
++c;
*c = ' ';
} else if (bLineComment || bBlockComment) {
*c = ' ';
}
}
}
}
P.S. the VB.NET is VS 2003, and the C++ is VC6 SP5.
Scratch that -- I just eliminated the last three functions I call in the C++ version and performance is up to 33ms per MB. That's almost a factor of 12 difference!PHP Code:void DeleteComments(char* cSrc)
{
bool bBlockComment = false,
bLineComment = false,
bQuote = false;
char* c,
cn;
// iterate through all the characters
for (c = cSrc; *c != NULL; ++c) {
if (*c == '\xD') { // '[backslash]xd'
// we have a carriage return
bLineComment = false;
if (bBlockComment)
*c = ' ';
continue;
} else {
cn = *(c + 1);
if (!(bLineComment || bBlockComment) && *c == '\\'') { // '[backslash]''
bQuote = !bQuote;
} else if (!bQuote) {
if (!(bLineComment || bBlockComment) && *c == '-' && cn == '-') {
bLineComment = true;
*c = ' ';
++c;
*c = ' ';
} else if (!bLineComment && *c == '/' && cn == '*') {
bBlockComment = true;
*c = ' ';
++c;
*c = ' ';
} else if (bBlockComment && *c == '*' && cn == '/') {
bBlockComment = false;
*c = ' ';
++c;
*c = ' ';
} else if (bLineComment || bBlockComment) {
*c = ' ';
}
}
}
}
}
change toVB Code:
c = Ctype(s,char)
VB Code:
c = s.ToCharArrayShould be on one line .... compiler optimizes for it then.VB Code:
ElseIf bLineComment OrElse bBlockComment Then c(iChar) = " "c End If
That should be immediately faster...
Before we go on, are you precompiling this .Net code or just using the JIT option??
Actually, your first suggestion, to use s.ToCharArray() is a tad slower! I'm not sure how to put the ElseIf statement on one line unless I take it out of the If block it's in, and then it takes longer. I tried Return c.ToString() instead of CStr(c) and it was faster, but I need to check that the two are functionally the same.
I am precompiling with Ctrl-F5.
VB.Net is slow. no other way to put it. even with really tiny applications consiting of basic forms and buttons, i am getting complaints.
it just takes ages for the forms to draw and for the events to fire. i find it doesn't matter whether it's the 1st or 101st time that a form is being drawn, it still takes forever.
is microsoft going to contiually release new versions every year forcing us to keep paying "rent" money for development environments? if so i am guessing that VS.Net 2004 will be lightening quick.....
just my $0.02
I wholeheartedly disagree Stingrae.
It will never be a fast as C++.... I don't know of any language besides Assembly that is...
But from the apps I've written so far, its extremely fast.
I think it almost the same. Because as most of the senior programmer known, the VB6 application require the VB runtime to be able it run under the windows. And also the VB.NET also require the dot net layer to execute.
And the dotnet Framework (windows version) is depend on the windows (kernel layer) to run.
So, as conclude. It waste a lot of processing cycle (Hz) to complete one instructions but this is to ensure it security.
My system:
AMD Athlon XP 2000+
1 GB DDR
The .NET framework will be slower, but for most needs, this does not matter. The development time needed is much less than C++, possibly even less than VB6. Now, if you're coding a photo-shop-like program, C++ IS the way to go. Or a CAD suite.
You should check that it is the CLR that is running slow and not your algorithm. If you are creating and destroying any graphics object in a loop, that's a red flag. The framework won't magically work right off -- you have to learn the intricacies of the GDI classes to really make it shine.
You say little forms with buttons bring complaints -- that could very well happen on machines with insufficient RAM or processors in the 300 MHz range. If that is so, these people will have to upgrade to see improvement -- the whole point of .NET is that it can improve productivity at some cost of speed & memory footprint, since hardware is so cheap these days. Unless you have a huge customer base, upgrading the hardware will probably be cheaper than coding in C++.