Visual Basic and software Design/Efficiency 
Author Message
 Visual Basic and software Design/Efficiency

Hi there,

Something that has been bothering me for a while now, and I have
attempted to read books about the subject, and have only found one Code
Complete. This book  discusses the topic of  Efficiency and also Tuning
at different levels, i.e. Algorithm level, Code level. I was  wondering,

when the ideal time is to start thinking of efficiency, some people say
at design time, when we are mulling over the problem and also
inventing/designing a solution for the problem. It does seems mighty
hard to think of both efficieny, correctness, reliability etc at the
same time, since how can efficiency be measured at this level precisely,

and if a guess is made hwo can this change also be measured to see if
indeed it has made a difference and has not compromised correctness. I
have now come to the conclusion after reading books by McConnell and MA
Jackson, that it is much more logical to first design a solution to be
Functional, and also have highly cohesive modules. If this program is
then found to be too slow, it is easy to just profile the program, and
then once bottlenecks are located to then work on these small areas,
either redesigning a new module or tuning the code, without affecting
the rest of the program structure.

How do you guys tackle this task, also your peers etc. Would be of great

benefit to me, to get some feedback on this topic, as I feel it is not
properly covered in the Software Engineering texts, some extracts in
Pressman and Somerville.

Alex



Mon, 27 May 2002 03:00:00 GMT  
 Visual Basic and software Design/Efficiency

Quote:
>...when the ideal time is to start thinking of efficiency...

# 1 - first make it WORK
# 2 - make sure it works CORRECTLY
# 3 - then make it work FAST


Tue, 28 May 2002 03:00:00 GMT  
 Visual Basic and software Design/Efficiency
Since Visual Basic is a VISUAL environment, you are actually programming the
moment you add your first form to your project, before any code is tied to
the program at all.  It is inherrantly possible to create an application in
which you type no code, yet create a completely inefficiant program.
Concepts such as Lightweight controls, Control Arrays, Object Groups, etc.
can all affect your program's performance, yet form design level objects are
very dificult to change once your application is completed.

Take, for example, a simple hilight script, applied to a textbox.  For one
or 2 textboxes, the following would not cause much of a problem:

(some code left out for simplicity)
Public Sub Text1_GotFocus()
    hilight(green)
End Sub

Public Sub Text2_GotFocus()
    hilight(red)
End Sub

...
...

once you get beyond 1 or 2 textboxes, this approach could be very
ineficient, and re-designing for code-reuse troublesome.  However, using a
Control Array at design time, long before the first test of your
application, could completely simplify the process of code-reuse.  for
example:

Public Sub Text1_GotFocus(Index As Integer)
    Select Case Index
        Case 1
            hilight(green)
        Case 2
            hilight(red)
        Case 3
            hilight(blue)
        ...
        ...
   Eend Select
End Sub

This may not seem to be much more efficient, but the controls in a control
array not only share the code which we have provided it, but all of the
intrinsic code for the control.  Since every '1' and '0' generatet by the
code must be loaded into memory, reducing repetativeness in design is a
necessary thing.  Also, if you were to change the name of your hilight
command to colorize, it would be much easier to find all the code which
calls your hilight procedure in the same place, not scattered throughout
your code modules.

I compiled an example program to see the difference a Control Array would
make, which was simply 1 form, with 10 text boxes.  Completely compiled, the
form with 10 individual text boxes was 12mb in size.  The form with 1
control array of 10 text boxes, only 4mb.  Reducing the program to 1/3 of
the original size is a compelling reason to consider Control Arrays.
However, converting to Control Arrays after code has been added to your form
is a complicated process which could bring unexpected errors.  It makes no
sense to overlook this type of design time optimization.

Another example of design time optimization is the use of a label versus a
text box.  Every textbox is actually a window, holding a hwind parameter.
Labels, on the other hand, are "Lightweight controls" which cannot be a
container, and therefore do not need a hwind parameter.  This gives them a
much smaller footprint.  The choice to use labels versus Textboxes should
not just be made on the basis of the overall look of the form, but also the
performance.  Granted, it is a fairly simplistic procedure to change your
textboxes to labels once the program is functional, but if you have 10 forms
with 10 text boxes to be converted, the 100 total conversions, including the
underlying code, could take days.  Making these sorts of decisions at design
time eliminates a large body of conversion time.

I apologize for being so long-winded, but the fact is, I have encountered
many, many other situations in which designing the application efficiently
eliminates many problems in the debugging stage, and attempting to re-design
an application for efficency only creates a second debugging stage.  Also,
there may be cases in which it is completely impossible to use a more
optimized control or function, if properties or methods of the inefficient
control are relied upon yet unavailible with the new control.

Basically, my point is that there are many points of design efficiency which
cannot be left to figure out after the fact, especially when designing with
objects which you have no control over.  When designing your own objects, it
is generally much easier to design your object around your code, then your
code around your object, then re-design your object around your code, then
re-design your code around your object.  However, when you are using objects
which you cannot control (the Microsoft Common Controls, for example) you
must consider efficiency in your design stages, since you cannot adjust the
control.

Again, I apologize for my long-winded statement, I just hope my statement
makes some sense and helps explain some of the reasons for design-time
optimizations.  Obviously, only trial & error, research, or experience will
describe different efficiency designs during design-time, but it is not a
step to completely ignore.

Andrew Counts


Quote:
> Hi there,

> Something that has been bothering me for a while now, and I have
> attempted to read books about the subject, and have only found one Code
> Complete. This book  discusses the topic of  Efficiency and also Tuning
> at different levels, i.e. Algorithm level, Code level. I was  wondering,

> when the ideal time is to start thinking of efficiency, some people say
> at design time, when we are mulling over the problem and also
> inventing/designing a solution for the problem. It does seems mighty
> hard to think of both efficieny, correctness, reliability etc at the
> same time, since how can efficiency be measured at this level precisely,

> and if a guess is made hwo can this change also be measured to see if
> indeed it has made a difference and has not compromised correctness. I
> have now come to the conclusion after reading books by McConnell and MA
> Jackson, that it is much more logical to first design a solution to be
> Functional, and also have highly cohesive modules. If this program is
> then found to be too slow, it is easy to just profile the program, and
> then once bottlenecks are located to then work on these small areas,
> either redesigning a new module or tuning the code, without affecting
> the rest of the program structure.

> How do you guys tackle this task, also your peers etc. Would be of great

> benefit to me, to get some feedback on this topic, as I feel it is not
> properly covered in the Software Engineering texts, some extracts in
> Pressman and Somerville.

> Alex



Tue, 28 May 2002 03:00:00 GMT  
 Visual Basic and software Design/Efficiency
My method is very similar:

# 1 - first make it WORK FAST
# 2 - make sure it works CORRECTLY FAST
# 3 - then make it work FASTER!

Jason


Quote:

> >...when the ideal time is to start thinking of efficiency...

> # 1 - first make it WORK
> # 2 - make sure it works CORRECTLY
> # 3 - then make it work FAST



Wed, 29 May 2002 03:00:00 GMT  
 
 [ 4 post ] 

 Relevant Pages 

1. project design software , compare website design software , web developers , website design software review , nof shop , software quality , nof 7.5 , bestellen preisvergleich , web site design , custom web design ,

2. Visual scheduling software for Visual Basic databases

3. FS: Visual Basic 5 books and Visual Studio 5 Enterprise software -- cheap

4. FS: Visual Basic 5 books and Visual Studio 5 Enterprise software

5. BASIC, VISUAL BASIC, C++, DELPHI SOFTWARE FRO CHEAP PRICE

6. Designing with Efficiency In mind

7. General Programming/Design/Efficiency with VB

8. Access opening Excel sheet in visual basic design mode

9. Visual Basic design problem

10. Urgent help - Error while opening Form design view on MS Visual Basic.Net

11. software I need to use visual basics-Doug knoxk

12. HELP WHAT SOFTWARE DO I NEED TO LEARN VISUAL BASICS

 

 
Powered by phpBB® Forum Software