Check this out:
http://msdn.microsoft.com/en-us/magazine/cc163340.aspx
Printable View
Check this out:
http://msdn.microsoft.com/en-us/magazine/cc163340.aspx
.net does not have huge requirements to run, though more power is always better it will run on a low end system.
For example right now I have it running on a 4 year old eMachine [shelf model $600 with monitor and OS] Only mod I made was to change the OS from XP home to Win2000 pro. VS loads slow but runs fine.
OK, I threw together a quick sample. I make little claims as to the optimization, but it looks pretty good to me. I used API calls for most of it, so hopefully the rewrite and thus comparison to .net should be fair. It tiles a bitmap over the form when you click on it, and gives the number of ticks in the TitleBar. So the larger the form, the longer it takes. Since it would normally not take long enough to really be meaningful, I just used a loop to multiply the number of calls to BitBlt. The number of redundant calls is determined by the value in a TextBox, so it can easily be adjusted for the machine it runs on.
Whomever wants to rewrite it in .net, go right ahead, and post the results. Obviously the same machine is going to need to run both versions to make a comparison.
Wiz, Can you upload the Image used, I dont have VB6 on this Dev system, and i'm busy with the .NET implimentation....
Thanks..
Sure. I've updated the zip file to include the image. Also, I noticed something in the code that shouldn't been there (left over from the project I used as a starting point), so I tweaked the code a bit.Quote:
Originally Posted by GremlinSA
OK, here's 'MY' Interpretation of the VB6 code..
There will be many other ways to interpret this, and some may be faster. I'm no VB.NET Graphics guru, however i have been looking up alot lately, for my articles, and this method was rated pretty high..
I've also left alot of the VB6 code in as comments, so that it can be easily compared..
BTW, the only API i left in was the GetTickCount, all the graphics work is done via the .NET framework, to give the comparason that we looking for..
I'm also going to build both and test run them, later..
Gremmy...
BTW. VB 2008 Framework 3.5..
--EDIT--
Updated File..
It would be interesting to see the same graphic representation in VB.Net using WPF.
Then someone should code the vb6 app in directx or even opengl since WPF uses directx.
Ouch.. is all i can say when you see the results..
Looks like I have a lot more to lookup...
Left is VB6 , right is .NET...
You need to recheck your facts with regard to WPF and DirectX.Quote:
Originally Posted by Joeman
No matter, you continue to miss the point. The point isn't about what underlying technology a framework uses (that is, if any underlying technologies are used at all) - it's about how the developer has to code against in the framework to get the work done.
Say I haven't heard too many comments from you on the other thread after it was shown that C# could be as fast (or faster) than C++ in the samples you provided.
100% agreement here. Using Extyernal GDI in VB6 or PInvoke in .Net really misses the whole point.Quote:
Originally Posted by Arjay
If you are going to have the work done by things that are not directly native to the language, then the tests become meaningless.
Consider. I can take the "Vb6" (quotes intentional) and make it a DLL rather than an EXE. This would not induce any difference in the benerated code. I could then load this DLL in a .Net application and PInvoke the identical code. Given that the tick measurement is inside the DLL, the results would be 100% identical.
I think that the different avenues being explored here have value. But they are NOT a measurement of the capabilities of what is provided by a specific evrinment.
How about the fastest possible VB6.0 application that contains NO "declare" statements what so ever....
Hmm, that whould be an interesting test..Quote:
Originally Posted by CPU
Try getting answers from a professional for c++ vs c#. To tell you the truth, I have only used c++ for little over a year. Maybe 1 1/2 at most. The little post we did was not a real test. You can't expect 20 lines of code to really compare for overall performance.. do you? Have you read this? http://en.wikipedia.org/wiki/Windows...ion_Foundation It clearly states directx in wpf.
As we found out about both test, c# either used more resources to wait for the object to be deleted which made it run faster or you didn't and got somewhat of a good memory range compared to c++ which was still peaking more resources than c++.
well I would use directx which comes with vb6 and not any declares.Quote:
Originally Posted by TheCpuWizard
This thread is getting bashed by now. I can't wait until microsoft pulls support for the .net 1.0, 1.1, 2.0, 3.0 ;) how many versions again? 4.. 5?? I think that cripples many things unless you stay current all the darn time.
I have to wonder what your motivation is regard to all this. By self admission you don't have any .Net experience, so how can you evaluate .Net? It seems to me that you just dislike MS.Quote:
Originally Posted by Joeman
lol you know nothing. when i said that c was faster than c++, I was referring to be used with opengl. My bad. Opengl interfaces with c better so it will run faster since you don't have much support for classes now do you? My experience is fine. If I was anti-microsoft, I wouldn't be in the c++ and winapi forum the most. Also I wouldn't be in vb6 thread stating it is just fine. I knew you would state about my experience with c++ and the time I have used it. You don't even know how the .net works, but I do. Sure I don't use it, but I know how it works. You didn't even know the wpf used directx. It took me 2-3 mins to find that out.. You sure you know the .net?