R
Roger
Truble said:
With some editing, the poster is correct:
Visual Studio .NET is not more efficient than
VB6. I can write a VB6 App that is at least twice as fast as
..NET.
and 1/10 th the size Roger
With some editing, the poster is correct:
Visual Studio .NET is not more efficient than
VB6. I can write a VB6 App that is at least twice as fast as
..NET.
and 1/10 th the size Roger
C
Codemonkey
Sounds like we've got challenge on our hands (and too much time 
How about a stupid wee challenge then? You write a *small* app in VB6 and
I'll try and replicate it in VB .net.
For VB6 to be "better" than VB.net it must meet the following criteria:
1) It must demonstrate a clear performance advantage (i.e. > 20%)
2) It must be half the size of the .net version
I don't think these criteria ar harsh - after all, you claim that you can
write one that is twice as fast and 1/10th the size!
Best Regards,
Trev.
How about a stupid wee challenge then? You write a *small* app in VB6 and
I'll try and replicate it in VB .net.
For VB6 to be "better" than VB.net it must meet the following criteria:
1) It must demonstrate a clear performance advantage (i.e. > 20%)
2) It must be half the size of the .net version
I don't think these criteria ar harsh - after all, you claim that you can
write one that is twice as fast and 1/10th the size!
Best Regards,
Trev.
R
Roger
Codemonkey said:Sounds like we've got challenge on our hands (and too much time
How about a stupid wee challenge then? You write a *small* app in VB6 and
I'll try and replicate it in VB .net.
For VB6 to be "better" than VB.net it must meet the following criteria:
1) It must demonstrate a clear performance advantage (i.e. > 20%)
Win98/ 64 meg, OK
I'm counting the runtime.
Why is everyone picking on Truble? I dont actually use VB6 but somebody's
got to take his side.
HTH,
Roger
S
Scott M.
Roger said:
You can't make a blanket statement like that about anything. But out of
curiosity, why would you say this? VB 6.0 was NEVER known for its
performance or efficiency. Why do you think that MS made most of their apps
in C not VB?
th the sizeI can write a VB6 App that is at least twice as fast as .NET.
This is not a measure of efficiency. The reason VB 6.0 does not requre as
much coding is because it was HDING a lot of cumbersome code in the
background. In some cases, this was helpful (ie. you don't have to worry
about creating an instance of your startup form - VB did it for you). In
many other cases, this is a detrement. What if you wanted to alter the way
VB 6.0 does something that it was HIDING from you? Tough luck, you had to
deal with it.
I'll give you a simple example of this....
If you created a form and placed numerous controls on the form and then at
some point wrote a loop that would iterate over the form's Controls
collection....
The order that the controls would be looked at in the loop would be the
order in which you created them on the form (not their sequential placement
on the form, the sequence was based on what control was CREATED first,
second, third, etc.).
In many cases, developers would use this technique for validating user input
on the form. But it's not very nice if the first control validated is the
6th one down on the form.
In VB 6.0, once the Controls collection is populated, that's it, you can't
alter the sequence of them (unless you delete all the controls and re-create
them or make a control array out of them and re-sequence their Indexes).
In VB.NET all you have to do to change the sequence of the controls is to
look at the line of generated code that adds the controls to the controls
collection (Controls.Add control1, control2, etc.) and re-order the
sequence on that line!
This is but one small example of how, in VB.NET, their may be more code to
deal with, but in return, you get MUCH more control over what is happening
and therefore you can fine tune an application MUCH BETTER than you ever
could before, which results is MUCH BETTER performance.
Also, by having certain general housekeeping functions running in the .NET
Framework, rather than your application (ie. Garbage Collection), your
application doesn't have to have that code in it, which results in more
streamlined programs (the .NET Framework runs in a different thread from the
application you built).
Give .NET a chance. I am a former VB 6.0 / Classic ASP person and I felt
like you did for about 6 months until the "light bulb" went off in my head
and I "got it".
..NET is by leaps and bounds far superior in almost all respects to VB 6.0.
Scott M.
C
Codemonkey
Win98/ 64 meg, OK
Shouldn't be too much a problem for a small App. VB6 will have an inital
advantage because of the smaller memory footprint, but once the .net has
been fully JITted, there shouldn't be much difference. Certinly not twice as
slow.
And what size are all the VB6 support files when you add them together?
(MSVBVM60.dll etc., etc.) Not as big as the .net framework, but imagine you
had to include all the different support files for simple tasks such as
network communication, database access, graphics, remoting etc. etc.
Granted, not all apps use these features, but it's nice to know that they're
already on a machine if you have to change your application to include them.
Nobody's picking on Truble. I'm disagreeing with Truble's point of view
Truble shouldn't make such bold statements without expecting someone else to
disagree and make their own bold statements
Trev.
Shouldn't be too much a problem for a small App. VB6 will have an inital
advantage because of the smaller memory footprint, but once the .net has
been fully JITted, there shouldn't be much difference. Certinly not twice as
slow.
And what size are all the VB6 support files when you add them together?
(MSVBVM60.dll etc., etc.) Not as big as the .net framework, but imagine you
had to include all the different support files for simple tasks such as
network communication, database access, graphics, remoting etc. etc.
Granted, not all apps use these features, but it's nice to know that they're
already on a machine if you have to change your application to include them.
Nobody's picking on Truble. I'm disagreeing with Truble's point of view
Truble shouldn't make such bold statements without expecting someone else to
disagree and make their own bold statements
Trev.
J
Jon Skeet [C# MVP]
Roger said:Win98/ 64 meg, OK
I'm counting the runtime.
In that case, are you including the VB runtime and anything that links
against in turn? Are you including the operating system itself, and if
so how much of it? It would make sense to do so, given that a lot of
the .NET framework is a load of libraries which most applications won't
use. (Each application will use some of the framework, very few
applications will directly use most of it.)
S
Scott M.
Roger said:Win98/ 64 meg, OK
I'm counting the runtime.
The fact that you would say this clearly indicates that you don't yet fully
understand .NET. The .NET Framework (what you call the runtime) is quite
large, but it contains much of what you would have (in VB 6) had to build
into your application.
Now, in VB 6, when you build all that into your application, it would all
need to execute in the same process (thread) and that was always one of VB
6's biggest drawbacks.
The .NET Framework runs in its own process and allows your application to
run in its own process, so it can execute faster. The fact that the
Framework is 24MB isn't relevant, since much of it is the vast class
libraries that are defined there. By the way, you wouldn't have references
to all those libraries anyway, so you can't count the full 24MB of the
Framework in your little experiment. You'd have to find a way to determine
the size of the libraries that you are using.
J
Jon Skeet [C# MVP]
Scott M. said:
Hang on a sec - you need to be very clear on the difference between a
process and a thread. They're quite different things...
J
Jerry Ham
Quite simple: They didn't.
S
Scott M.
You are correct that one process can be running many threads within it. My
point was that since much of the "grunt" work of a .NET application is done
in its own thread, the main application is not encumbered by the Framework
doing its thing and in a VB 6 application, you would have everything
happening in one thread.
point was that since much of the "grunt" work of a .NET application is done
in its own thread, the main application is not encumbered by the Framework
doing its thing and in a VB 6 application, you would have everything
happening in one thread.
J
Jon Skeet [C# MVP]
Scott M. said:
You give the impression that "the framework" is running in one thread,
and the application is done in another, why is entirely inaccurate.
*All* the threads in an app are running "the framework", other than
those which entirely run unmanaged code.
If you mean that the GUI thread is easily separated from worker
threads, I agree with you - but that's a very different matter.
S
Scott M.
Jon Skeet said:
Well no, not really. The GC for example runs within the framework and in a
different thread than the .NET application it services. This is beneficial
because when the GC kicks in to do its thing, it does not impede the thread
the main application is running in. This is one of the reasons not to
invoke the GC directly from within a .NET application. If you do, you will
bring the GC's processing into the main application's thread and possibly
reduce its performance.
J
Jon Skeet [C# MVP]
Scott M. said:
Well, potentially - depending on machine configuration - but that's
very different from giving the impression that the *whole* framework
runs in a different thread. There are *lots* of threads (potentially)
some of which may be running your own code, some of which may be
running "purely framework" code - but you're unlikely to get very far
in *any* thread without running "framework code".
Basically I'm not at all sure what your argument about comparing .NET
to VB is here, because it seems somewhat confused.
G
Guest
One a single CPU, it makes a difference.
Why do so many people think Threads = concurrency on a single proc?`
Probably the worlds largest misconception
Why do so many people think Threads = concurrency on a single proc?`
Probably the worlds largest misconception
Scott M. said:
C
Codemonkey
Quite simple: They didn't.
Exactly. Microsoft didn't ruin VB6 at all. VB6 hasn't changed, and most
likley will not change - it will always be VB6 If you don't like VB.net,
then Microsoft hasn't stopped you from using VB6 if you want to.
Exactly. Microsoft didn't ruin VB6 at all. VB6 hasn't changed, and most
likley will not change - it will always be VB6
If you don't like VB.net,then Microsoft hasn't stopped you from using VB6 if you want to.
J
Jon Skeet [C# MVP]
Well, threads *do* make it easy *sort* of do two things at once, so
long as one of them is "waiting for something else to happen". Even on
a single processor, correct use of threads is enormously important.
S
Scott M.
Jon Skeet said:
Jon, my point is very simple, but your too close to the fire to see the
flame. In a VB 6 application, you not only had to write code for your app
to work, but you also had to write additional code for "housekeeping"
purposes and all that code ran in a single thread (usually).
In .NET, there is a very distinct separation between what you have to write
and what is already written into the Framework. And, as is the case with the
GC, you have the ability to put different actions into different threads.
This is a very simple point, but you've been "picking" at the definition of
process and thread, which is useful to understand but not the point of the
original post.
J
Jon Skeet [C# MVP]
Scott M. said:
It strikes me you've got three points here:
1) .NET provides good multi-threading capabilities
2) .NET gives a good garbage collection system
3) .NET has a very extensive library which does a lot of things you may
have had to write yourself beforehand
All those three things are true, but you seem to be conflating them
when they are very separate things.
(In terms of GC occurring in separate threads, I believe the "normal"
CLR actually has a stop-the-world GC - it's finalization that occurs in
another thread. A different CLR typically used on multi-processor
machines has a concurrent GC.)
G
Guest
One a single CPU does it bloody matter , its stop the world anyway. Geez.
S
Scott M.
Jon, you're right in what you say, but again, you are missing the point.
Look at the subject of this thread. I'm trying to point out the advantages
of VB.NET over VB 6.0.
In today's world, it is not uncommon to work with more than one processor or
HyperThreaded processors. A VB 6.0 app would have a hard time taking
advantage of this. In .NET, this can be leveraged and is certainly ONE of
the many advantages of VB.NET.
Look at the subject of this thread. I'm trying to point out the advantages
of VB.NET over VB 6.0.
In today's world, it is not uncommon to work with more than one processor or
HyperThreaded processors. A VB 6.0 app would have a hard time taking
advantage of this. In .NET, this can be leveraged and is certainly ONE of
the many advantages of VB.NET.