Replacing non-visual components with code

Question

Is "Replacing non-visual components with code" a proven optimization technique in Delphi 7. Mainly with respect to Database Access.

Fenwick

Can you provide any references to blogs or whatever that recommend it? I've never heard of it before (which doesn't mean anything, of course :) – Karyotin

see point no. 8 in delphi.about.com/od/objectpascalide/a/speedsize.htm – Fenwick

btw, gexperts is great add-in that converts components to code. – Tennietenniel

Yes, on P-I's with 8MB. On normal machines I wouldn't worry. – Whisker

Answer 1

The Web site you cite talks about replacing a dialog-box component with code that would display the dialog box without the use of any component. The alternative is to write a couple of lines of code to set up and display a dialog box whenever you need one, and to skip the component altogether. It's not really an optimization in speed or size, though. It's not a speed optimization since your code would do exactly what a component would have done anyway, and it's not a size optimization because the space any one component occupies in a program is negligible.

Database components aren't so easily replaceable as dialog-box components. Nearly everything in Delphi is designed to use descendants of the standard database components. If you don't use the components, then you won't be using any of Delphi's database capabilities at all. You can use the database libraries' native APIs if you wish, but I think that would be foolish if your goal is really optimization and you haven't identified the components as the source of your program's non-optimal behavior. Consider how much time and effort it would take you to rewrite your program without the database components.

Veronicaveronika

dialog-box components is just cited as an example. If an object is created of the same class as of the component then all the database capabilities of Delphi will be available. Please correct me If I am wrong in assuming the above said thing. – Fenwick

You're correct just now, but confused. You think the advice was to instantiate the components manually instead of dropping them on a form or data module. For database components, that gives you no benefit. In fact, the advice was to not use the components at all. For database components, that's a really bad idea. – Veronicaveronika

Answer 2

I don't see how a form-based dataset/query/table/etc., would be faster or slower than one created in code. However, I like to put them in code as it's easier to maintain. I've seen screens with SQL embedded in a component, and then it's overridden in the code. Then I have to stop and investigate to determine which SQL is actually in effect. Sometimes the SQL in the form is good, sometimes it's used for a while and then trumped by the code, sometimes it's never active and the SQL is trumped in the formcreate. So I have to determine whether this is by design, or just sloppy leftovers. Also, it's easy to miss SQL changes in code reviews if they're in the .DFM and not the .PAS. i.e. I don't always look at the .DFM because I'm not interested in whether a label caption changed or a button moved.

So while it's nice for prototyping, when it comes to production code, you're better off having all of your database logic (SQL, table and field definitions) in the .pas file.

Update: I have finally given CnPack a try. Among the dozens of goodies, is a brilliant tool called "convert selected components to code". Form Design Wizard | More... | Convert Selected Components To Code. It does it all for you.

Track

This is what I am planning to do. The code-base on which I am working right now is an inherited one and not what I have created. So I think it will take time to move all the sql logic from the .dfm file to the .pas file – Fenwick

@Vinayek - you will not be sorry. Also double-check to ensure that all tables, database connectors, sessions, etc., are set to be inactive. If you find any that ARE active, then be extra careful in the code to ensure that you open the connections yourself. i.e. you may have forms that "get lucky" because the database actually does reside where the original author thought it would. – Track

Thanks for the advice. I have just started rewriting the data access part of the code. – Fenwick

Answer 3

This is not a matter of being a component or not a component. If it comes to database access then BDE is extremely slow so changing it for sth else is a good move.

By the way - optimization is not about 'proven techniques' - it's about identifying a problem and solving it. If the problem happens to be slow db access then this is what you have to change.

Graminivorous

Regarding Database Access I am using ado objects and not bde because I am more familiar with ado. – Fenwick

Answer 4

Generally no. There is no additional overhead in using a non-visual component. It is created very quickly and works at runtime exactly at the same speed as one "created in code".

Luzluzader

If the non-visual component is replaced by code then certain non-visual components which were used only in a single procedure will be removed from the memory once the procedure has finished execution. I am mainly talking about data-access components. – Fenwick