[RESOLVED] Implementing a Inc() function in VB6

Hi Guys...

I am an old Delphi programmer and have taken over a VB6 (sp6) project that has millions of lines of code...

I am trying to make some functions and processes in the code more efficient by rewriting some of the functions.

There are a lot of i= i+1 type lines in the code that are driving me crazy so I am trying to implement a inc() function that works as it does in Delphi...

I have this sub;

Public Sub Incr(ByRef VValue As Long, Optional Increment As Long = 1)
' Returns vValue increased by 'Increment' value
VValue = VValue + Increment
End Sub

I have tried passing the value both ByRef and ByVal.

If I use a standalone variable (e.g. lCounter) and pass it to this sub, it returns with the number incremented. I use it in this fashion;

Do while something
incr (lcounter)
Loop

If I pass it a value from a control, e.g. progbar1.value, it does not increment the value... it comes back = 0 (zero) every time.

Do while something
incr (progbar1.value)
Loop

Can someone give me some insight as to why it wont increment my progress bar value?

Thanks for the assist.

Incr will just run slow and be clumsy to read anyway.

Using parens around a Sub's arguments list is not only awkward but can have undesired consequences.

Passing byref is more likely to get better results but not on a property.

You should be using a function, not a sub, try,

Code:

---

Public function Incr(ByVal VValue As Long, Optional Increment As Long = 1) as long
' Returns vValue increased by 'Increment' value
VValue = VValue + Increment
End Sub

---

You want to return a value.

[QUOTE=Jmacp;3961284]You should be using a function, not a sub...QUOTE]

But you used it as sub anyway. You probably ment to do this instead:

Code:

---

Public Function Incr(ByVal VValue As Long, Optional Increment As Long = 1) As Long
' Returns vValue increased by 'Increment' value
Incr = VValue + Increment
End Function

---

Quote:

---

Originally Posted by Jmacp

You should be using a function, not a sub, try,

Code:

---

Public function Incr(ByVal VValue As Long, Optional Increment As Long = 1) as long
' Returns vValue increased by 'Increment' value
VValue = VValue + Increment
End Sub

---

You want to return a value.

---

It actually was a function, but what I am trying to accomplish is not having to assign it to itself like progbar1.value = incr(progbar1.value). I just want to say incr progbar1.value and optionally pass a multiplier.

It may look odd coming from a different language background, but

progbar1.value = progbar1.value + 1 is the most efficient and straight forward way of incrementing. Whether it be a loop value, property value, whatever. If you call a function to do the incrementing then you naturally slow down your code.

The reason, as mentioned by dilettante, that your progressbar didn't change was that you were passing its value and incrementing that. You weren't passing the object's property. What you are passing is the current value of the property, not the property itself. And there's no real way around it.

As mentioned in other replies, you could use a function or you could create a specialized method for each type of object and its property. Many controls have a Value property, but not all. And not all value properties can be incremented as some are boolean. It might look like this....

Code:

---

Public Sub IncObj(TheObject As Object, Optional StepValue As Long = 1)
    TheObject.Value = TheObject.Value + StepValue
    ' note that if the object does not have a Value property name, error will result
    ' also if the value exceeds the maximum allowed, error
End Sub

Public Sub IncLong(TheValue As Long, Optional StepValue As Long = 1)
    TheValue = TheValue + StepValue
End Sub

Sample calls might look like:
:: IncObj progBar1, 1
:: Dim X As Long: IncLong X, 1

---

And a generic combination would look like this, though you have just slowed down your code a ton

Code:

---

Public Sub Inc(TheTarget As Variant, Optional StepValue As Long = 1)
    If IsObject(TheTarget) Then
        TheTarget.Value = TheTarget.Value + StepValue
        ' note that if the object does not have a Value property name, error will result
    Else
        TheTarget = TheTarget + StepValue
    End If
    ' if the new value exceeds the min/max allowed, error
End Sub

Sample calls might look like:
:: Inc progBar1, 1
:: Dim X As Long: Inc X, 5

---

Quote:

---

Originally Posted by dilettante

Incr will just run slow and be clumsy to read anyway.

---

For what it's worth, I concur with Dilettante. Constructs such as i = i + 1 are not inefficient and are very easy to read and understand. Wrapping them into a Function / Subroutine will reduce efficiency, especially if there ae lots of them.

I would concentrate on reducing the total number of instructions executed, rather than increasing them. This will probably mean re-structuring some of the code. Have you performed any analysis to determine specific areas of 'inefficiency'? ie are there any Subroutines / Functions that run for excessive lengths of time? I'd concentrate on those first, then pick off the 'minor ones' as and when.

My guess is that if the project has 'millions of lines of code' (which begs the question, why?) there are plenty of opportunities for improvements.

[QUOTE=RhinoBull;3961299]

Quote:

---

Originally Posted by Jmacp

You should be using a function, not a sub...QUOTE]

But you used it as sub anyway. You probably ment to do this instead:

Code:

---

Public Function Incr(ByVal VValue As Long, Optional Increment As Long = 1) As Long
' Returns vValue increased by 'Increment' value
Incr = VValue + Increment
End Function

---

---

Your right, i had a bit too much wine last night ....

The x86 instruction set includes an "INC" (increment) instruction. I imagine any sane compiler will optimize "x = x + 1" to use the INC instruction instead of integer addition. The easier it is for the compiler to recognize this optimization, the better. Obfuscating it with a function call and another parameter might be too much for VB6 to handle, resulting in less efficient code (even assuming the function was inlined). It would make sense if this was the reason Delphi included the function in the first place--as a convenience to the compiler writers.

Not to mention the fact that the values would have to be pushed on to/ popped off the stack before, during and after the call to the sub/function.

-tg

Quote:

---

Originally Posted by Doogle

For what it's worth, I concur with Dilettante. Constructs such as i = i + 1 are not inefficient and are very easy to read and understand. Wrapping them into a Function / Subroutine will reduce efficiency, especially if there ae lots of them.

I would concentrate on reducing the total number of instructions executed, rather than increasing them. This will probably mean re-structuring some of the code. Have you performed any analysis to determine specific areas of 'inefficiency'? ie are there any Subroutines / Functions that run for excessive lengths of time? I'd concentrate on those first, then pick off the 'minor ones' as and when.

My guess is that if the project has 'millions of lines of code' (which begs the question, why?) there are plenty of opportunities for improvements.

---

Thank you for the input guys... I really appreciate it. I get it, I get it... not such a good idea... ok.

As for the millions of lines of code, ok, I exaggerated a little :D, 1.2 million lines of VB6 code all together... it's a commercial application that's been on the market a long time (cant say the name). The person that wrote it initially did some things in code that I have been trying for quite a while to figure out how to undo that were so convoluted and undocumented that I have been reworking it a little bit at a time to make it run faster, more reliable and efficiently.

The only way we could get this over to .NET is to rewrite it, which the company is not willing to do because of the cost of development. Most automated conversion programs that I have tried choke on it and leave way too much work after the conversion, so we'll leave it on this platform. There are also COM and ActiveX controls and DLL's and a couple of integrated SDK's that were never ported to .Net that would make it very difficult to convert, thus it would have to be rewritten.

I work with both .NET (VS2010) and VB6 and I personally I like VB6 compared to .NET... VB6 development is much faster, the apps seem to run faster and for the most part there is a way to accomplish almost every task that needs to be done.

Thanks again peeps :wave:

You're welcome.

If it makes any difference those aren't bad ideas, they just fight the platform and the result can be worse than what you started with.

I think most of us would have appreciated a modernization path with better compatibility than VB.Net offered. By now we'd be using VB 10.0 looking forward to 11.0 with any number of language improvements along the way. It just wasn't in the cards though. A company as big as Microsoft surely has the resources, but they didn't want to see their tools market fragmented.

You can see much the same thing in the timid way VBA has been updated in the Office products.

So in the end VB6 "is what it is" and ever will be.

I'd throw a guess these days processors are already pretty intelligent beasts as well and have some capabilities for self optimization. From what I've heard is that some of the latest "fast" VB6 code I've written has performed relatively poorly on a Pentium 4 processor while any modern processor sold in the past five years or so has done well.

But VB6's compiler isn't a very intelligent one in general. Since 1997 things have really changed when it comes to intelligence of compilers and their code optimization, especially in the C/C++ world where you can write code that is total "after cow" and the compiler optimizes it so that it seems what you've written is brilliant. In the other hand these intelligent optimizations may also break your code and/or introduce new bugs.

You can write fast VB6 code, but the lack of implementation for certain instructions, datatypes and especially limitation to safe arrays for any memory access prevents the greatest ASM level competition that some C code can get into thanks to the intelligence of the compiler.


As for the topic... avoiding variable = variable + 1 with a procedure is silly, you only drop the performance significantly :)

It is far better to look at things from algorithm perspective (great algorithm with poor code is almost always better than poor algorithm with excellent code!) as well as have a look at how strings are handled. String concatenation is a bottleneck for all strings that may grow over some 32 000 characters and gives a noticeable speed drop in loops.


Edit!
Wow, many replies in the meanwhile.

Yes, one problem is that we're stuck with the ancient C2.exe that is a thinly-veiled part of the VC++ 6.0 compiler. This could have updated much more cheaply than creating a whole new version of VB but there wasn't enough incentive.

I haven't looked for a while, but I think it topped out at Pentium Pro optimizations. [Duh - This switch is available in the VB6 IDE's Project Properties dialog.]

Normal C2s are DLLs as far as I recall, and they don't include the ability to process the "IL" produced by the VB6 front-end compiler anymore after VC++ 6.0.