Why is VB6 Edit-And-Continue function so good in comparison to VB.NET?

Hello!

I totally love how I could press the Pause button, then edit my code and press the Play button again.
VB6 would IMMEDIATELY (I mean literally without ANY delay) continue to work with the new / edited code.
This is simply amazing.

When I try to do the same with VB.NET, it either takes ages (several seconds) for VB.NET to choke on it, or it would say that it can't edit this on the fly and needs to restart debugging.

In contrast to that, VB6 is sooo forgiving.
There are a few things that I may not do, like deleting variables, but 99% of the time it allows really wild changes like editing nested for-next-statements.

How could it do that so amazingly well?

Thank you!

Quote:

---

Originally Posted by tmighty2

How could it do that so amazingly well?

---

https://www.vbforums.com/images/ieimages/2021/11/1.gif

Hehe. That's why I think, too, but I wanted to know the trick behind it from a magician. :-)

https://www.vbforums.com/images/ieimages/2021/11/6.png

Not today. Sorry.

As far as speed goes there is a huge difference in just about any program that was designed when PCs had 8 megs of ram and a 200mhz processor vs the ones designed for modern systems.

That said I have a system running 6 core 3.5ghz Windows 7x64 which developed a problem with one of the ram slots so I am forced to use it with a single 4gb chip for now. VB6 is absolutely painfully slow on that system right now. Much slower than VB2017 on my newer system.

I never had a problem with VB6 running on a Dell E5400 core 2duo with Win7 64bit on 4gb RAM. VB6 flew and that speed is what reminded me there was life in the old dog yet.

One of my test systems is VB6 on core i5 running Win7 >32bit< just 4gb RAM and that also flies with all my programs some of them reasonably large. IDE, compilation the lot all run v.quickly.

Your system...

Re: the OP. VB.NET's edit and continue is rather differently implemented. I understand that you are running a real binary and the debugger keeps a track of the memory location where you paused the RUN operation, inserting you back at that point when you restart. Someone here will correct me or expound further on how it occurs.

32 bit systems work fine with 4gb. Any more ram is a waste in a 32bit system.

The system I was referring to may have additional problems. It started blue screening a while back. After much trial and error I found that it I removed one of the ram chips it was much more stable though still blue screens on startup from time to time. It is painfully slow. I had to load up a VB6 project last week to make a quick change and it must have taken a full minute to load the vbp and it is not a very big project. The resulting exe is under 500k.

The system that is struggling is a Phenom 2 1100T It was running 8bg ram and I had been using it for years with no issues so who knows what the real issue is. All I know is there was a huge drop off in performance when I had to remove the ram chip.

As for the edit and continue. VB6 I think compiles each routine as it is called so you can have quite a lot of freedom in editing a routine so long as the current code execution point is not within that routine. When it is VB6 will usually tell you that you need to restart the program to apply the changes.

vb6 is old and therefore also need less memory, so the idea that 4GB would make vb6 slow is odd.
I think theres something else not working affection vb6.
speed should be all about cpu and not so much the memory size.
and vb6 is 32bit, and can only use up to 4GB anyway.

He just threw that in to disrupt the whole thread... not deliberately, but it did the job anyway.
His 4gb RAM has nothing to do with anything on this planet.

The OP is just impressed with VB6's abilities, that's it.

Quote:

---

Originally Posted by baka

vb6 is old and therefore also need less memory, so the idea that 4GB would make vb6 slow is odd.
I think theres something else not working affection vb6.
speed should be all about cpu and not so much the memory size.
and vb6 is 32bit, and can only use up to 4GB anyway.

---

Yes I know VB6 is 32 bit but Windows 7 64 uses quite a bit of that ram. I always go with at least 8gb for a 64 bit system but yes there is something else going on. I have never saw VB6 perform that poorly on any system in the past.

Open up a separate thread then, let this hijacked one get back on track and we can try to help you on your own specific problem.

Quote:

---

Originally Posted by DataMiser

...VB6 I think compiles each routine as it is called so you can have quite a lot of freedom in editing a routine so long as the current code execution point is not within that routine. When it is VB6 will usually tell you that you need to restart the program to apply the changes.

---

That is not correct. You can also make many changes in VB if the code is kept in the currently executed procedure. It is only problematic in wrapped lines (with _ at the end of the line), in with-constructs and in the select-case conditions. Of course, you may not delete a variable that has already been initialised, but you must declare and use new variables.

Note on memory: As a 32-bit system, VB can only address 4GB and must share this memory with the operating system. This is why VB6 does better on a 64-bit system, because (theoretically) it does not have to share the 4GB.

Ideal environment for VB6: Win7 64Bit (without Aero) + 8GB memory or more. W. Wolf

Quote:

---

Originally Posted by wwolf

Ideal environment for VB6: Win7 64Bit (without Aero) + 8GB memory or more.

---

That is exactly what I use.

Quote:

---

Originally Posted by tmighty2

I totally love how I could press the Pause button, then edit my code and press the Play button again.
VB6 would IMMEDIATELY (I mean literally without ANY delay) continue to work with the new / edited code.
This is simply amazing.

---

VS22 now has a "Hot Reload". Don't know if this is as good (or better) as E&C in VB6. The E&C in older VS versions is definitely worse. In terms of RAD, VB6 is unsurpassed so far. W. Wolf

Well, my effective work is with highway, drainage and road signaling projects. I have a lot of software to do this. Of course, each program has its tools, interactivity, among other things. But unfortunately I'm stuck in a program that dates back to 1998, as it gives me the versatility to be able to edit project components. I have other more modern and powerful software, but it doesn't allow me such versatility.

I'm talking about road projects, I'm not talking about VB or VB.Net. But compared to my working tool, the 1998 program was done in Delphi, the others in NET 3.5 and later platforms.

What I want to say in my analysis of what rules is the way the software was thought before its implementation. If NET developers with their very powerful framework do not do a good planning they can run the risk of falling behind in certain questions by their competitors.

If VB6 is faster as announced in the post, it could be some swelling of the power of the NET platform. NET has several layers that VB6 does not have.

I suspect you may be right on that. Framework .NET created IL, which was then compiled into executable code. The intention was to compete with Java with the promise of Write Once Run Anywhere, which .NET managed, but neither did Java. The thought was that platform specific JIT compilers could be built to turn the IL into platform specific exes. It was an interesting idea that was in vogue at the time, but consider what impact it would have on edit and continue. Instead of going from source to compiled binary, you are going from source to IL...and then do the JIT compile from IL to exe. I have no idea whether or not this is the case, but I could believe that even a minor change in the source would result in only moderately different IL, but would also cause the JIT compiler to re-compile the whole program. That would certainly account for a long edit and continue pause, because a small change to the source would result in a large change to the final exe.

I don't know if that's true, though, it's just speculation on my part. I have never used edit and continue in .NET. I've been vaguely aware that it is there, but it hasn't really mattered to me, especially since so much of my work is in a realm where it just doesn't matter (plugins, where edit and continue is meaningless). Therefore, the difference might also be going away with .NET 5 and .NET 6, which don't have the IL, necessarily. So, if my speculation is correct, then the situation might improve...and I still won't know.