Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>The first thing I need to mention is that .Net code <em>never</em> runs in a VM. While it's true .Net programs are compiled to IL that is somewhat analogous to Java's ByteCode, the important difference is that the IL is also in turn compiled to fully native code before the app starts, rather than interpreted by a VM.</p> <p>Moving on to the .Net/VB6 comparison. I can't point to specific data, but from personal experience it depends on what you're doing.</p> <p>To illustrate this, let's think about six different benchmark applications, each with a vb6 and .Net version. Each application picks out a specific operation, performs it 100,000 times, and then records the amount of time taken. Note that this is a thought experiment: I haven't actually seen results from real apps. But I feel like I have a sense of the strengths and weaknesses of both platforms.</p> <ul> <li><p>Application A does some serious cpu-heavy number crunching. In this case, I have to believe the results here would be almost identical. Both VB6 and .Net compile down to native code, and so a cpu <code>mult</code> instruction is the same regardless. That said, if you're not using <code>Option Strict</code> you could quickly get yourself in trouble on either platform. Since you used C# (which essentially is always <code>Option Strict</code>), that could give your .Net code an advantage.</p></li> <li><p>Application B goes out and retrieves a value from a database. Again, results are probably very close, though I'd have to give .Net a very slight edge for two reasons: it uses a native sql client, which is supposedly a little faster, and it does things like automatic connection pooling and makes it easier to factor out things like connecting once and re-using that connection rather than connecting repeatedly. But if you compare apples to apples as far as code goes, the two will likely be very close.</p></li> <li><p>Application C shows and hides a form repeatedly. Here I would have to give vb6 the nod. It's based on an older, less glitzy widget set which will frankly be cheaper to render. Also, the WinForms components aren't known for being all that speedy. However, the difference probably isn't as large as you might think, and you're probably not completely redrawing forms that often, either. This is likely the slowness that your users complain about.</p></li> <li><p>Application D is based on string operations, and here I have to give the nod to .Net. Both VB6 and .Net are known for slow string operations. However, .Net provides a number of tools that are simply not available in vb6 to help developers overcome the slowness. That said, if you're not aware of those tools, poor string operation choices could easily bog down your app doing useless work. This is also likely contributing to user complaints.</p></li> <li><p>Application E is going to repeatedly load an Xml document into memory. Again, I have to think that .Net would have an advantage. First of all the xml tools available to vb were primitive at best. I find it unlikely they haven't been improved significantly. Additionally, .Net's garbage collector is pretty smart, giving it an advantage or allocated and freeing memory during the loads. However, I think the biggest thing here is going to be disk speed, which means the difference wouldn't be that large.</p></li> <li><p>Application F will repeatedly start a .Net or vb6 program, wait for it to become ready (for some definition of "ready"), and then close it. Here vb6 likely has the advantage, for two reasons. Firstly, the .Net has to compile the IL to bytecode on the first run. Thankfully, that's only the first run. Seconly, the .Net app also has to load any referenced assemblies. By comparison, the VB6 runtime is <em>much</em> smaller. However, this is normally only true the <em>first</em> time you start the app on a particular machine, and there are ways to pre-compile the .Net code. This may also contribute to perceived slowness.</p></li> </ul> <p>One important point is that for all of these applications, the .Net app is likely going to have a <em>much</em> larger memory footprint. For some reasons developers tend to think about this as a bad performance characteristic when in fact the opposite is true. If your app is using more memory, it's probably spending less time going to disk, and the disk is slower by far. It's probably also caching more, which saves cpu time. And for .Net specifically, it's saving up allocation/deallocation operations for periods when it's more important or when the pc is otherwise idle.</p> <p>I don't have time, but it's be interesting to see someone use the StopWatch implementation (at least for the .Net side) mentioned in <a href="http://www.codinghorror.com/blog/archives/001178.html" rel="nofollow noreferrer">today's Coding Horror</a> to get real benchmarks for each of these.</p>
    singulars
    1. This table or related slice is empty.
    1. POWhat is the best way to compare .NET performance vs. VB 6 performance at a customer site?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USJoel Coehoorn
    1. USJoel Coehoorn
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POWhat is the best way to compare .NET performance vs. VB 6 performance at a customer site?
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COI don't quite follow the argument that the .Net app will spend less time going to disk. Programs with a large memory footprint *might* spend less time going to disk, *if* that memory is being used to cache data. But I don't think that's true here: the .Net app is using more memory simply because the runtime libraries are bigger. That's not providing any extra disk caching. If anything, it's *potentially reducing* disk caching by requiring memory that might otherwise be available for disk caching by the operating system.
      singulars
      1. PO
      1. USMarkJ
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload