Hi,

I'm looking at ways to enhance the performance of my applicaitons. With
most of my applicaitons I have two things happening when a form opens
that takes some time:

1) Executing and Opening Queries and Tables.

2) Creating, scaling and showing the form. (Using TElasticForm component).

On my larger forms with lots of data, both these tasks can take 3+
seconds each to complete their operation making it 6+ seconds for a form
to calculate and display.

I read somewhere recently that the traditional approach to speeding up
programs ("We'll just wait for the next generation of hardware.")
doesn't work anymore because systems are designed to be multi-threaded
now for more performance.

I haven't run much with threads in the past (they scare me), but if it's
the way to go I guess it's time to start looking.

I know a few others here use EDB or DBISam and ElasticForm. I was just
wondering if anyone has tried this themselves on their applications and
if it's been successful (and how difficult it is, etc ?

Cheers

Adam.

Adam


What can be done will depend a lot on your design.

I'm guessing that you have some sort of tabbed controls with wadges of controls on each page all of which has to be loaded and sized when the form is opened. If so a better approach is to use frames or (as I do) parented forms and only create the bit needed for a page when it is viewed.

First, without knowing how truly complex your forms are, I have difficulty believing 3 secs to instantiate a form even given that its being rescaled using ElasticForm.

Second, threads may or may not help depending on how much work needs to be done before your form becomes usable. ie its no use your form becoming available in 0.5 seconds if the user still has to wait for 5 seconds before they can start doing anything.

Assuming my guess about tabbed controls is right then one way threads could be used is if the user is always presented with the same page on opening the form then open the tables/queries necessary for that in the foreground and open the remainder in threads. You'd need to be careful to make queries thread safe when presenting the results back to the user. If you're using memory or temprary tables it would become much easier.

I moved from a paradigm of having all the tables on one datamodule and opening all of them when the app is created to having a copy of the tables that are used for lookup on a datamodule and each form having its own collection, and with the majority of the lookup tables being opened only as and when needed. The original design was based on usage of Paradox/BDE/W95 so I had to keep handles used to a minimum. That's no longer a consideration so this is faster.

If you want to email me a sample I can make more informed comments.

Roy Lambert [Team Elevate]

Hi Roy,

> I'm guessing that you have some sort of tabbed controls with wadges of controls on each page all of which has to be loaded and sized when the form is opened. If so a better approach is to use frames or (as I do) parented forms and only create the bit needed for a page when it is viewed.

I might need to try this approach and see what sort of difference it
makes. You are correct in that I do have a number of page control
components on the form containing different components.

> First, without knowing how truly complex your forms are, I have difficulty believing 3 secs to instantiate a form even given that its being rescaled using ElasticForm.

Actually, one of my test forms takes 8 seconds when I set the forms
visible property from false to TRUE. I can reduce this a little more
than 1/2 if I turn off Scale Forms. (That was one of the reasons I
upgraded, hoping that there was some sort of speed improvement.
Unfortunately I had more issues with the upgrade and dropped back down
again to v4). Changing to what you recommended (having the other tabs as
forms may help).

> Second, threads may or may not help depending on how much work needs to be done before your form becomes usable. ie its no use your form becoming available in 0.5 seconds if the user still has to wait for 5 seconds before they can start doing anything.

Agreed. I thought if I have the main thread open the datasets (so I
don't have any issues with DBISam and threads) and use a second thread
to do the form loading, visible, scaling, etc that might increase the speed.

The main reason I thought this was the comment I read on a upcoming
Delphi Users Group Conference here in Australia. (Which unfortunately I
can't attend).

The impression I got is that computers aren't going to get any faster
any more, but instead are going to have more cores. In order to be able
to use the extra processing we need to start designing applications with
multiple threads, simply 'waiting' for a faster computer isn't going to
work like the old days.


> Assuming my guess about tabbed controls is right then one way threads could be used is if the user is always presented with the same page on opening the form then open the tables/queries necessary for that in the foreground and open the remainder in threads. You'd need to be careful to make queries thread safe when presenting the results back to the user. If you're using memory or temprary tables it would become much easier.

That pretty much happens at the moment. One of the issues I have is the
amount of 'lookup' queries I have where information is displayed on the
main page. My current guess is approx 50% form load time, 50% dataset
opening time. I figured if I could perform both these operations at the
same time using threads I could effectively halve


> I moved from a paradigm of having all the tables on one datamodule and opening all of them when the app is created to having a copy of the tables that are used for lookup on a datamodule and each form having its own collection, and with the majority of the lookup tables being opened only as and when needed. The original design was based on usage of Paradox/BDE/W95 so I had to keep handles used to a minimum. That's no longer a consideration so this is faster.

Same way I used to design too. Now I do as you do, each form effectively
has it's own Datamodule that loads when the form loads. (or just before
the form loads)

> If you want to email me a sample I can make more informed comments.

The main application will be too difficult to send through to you with
the amount of 3rd party components that are on there. However I do have
a test application I made with scaleform (the one that takes ~8 seconds
to load), but it doesn't have datasets on there. It uses forms that are
placed onto a pagecontrol. It's loaded with quite a number of cx controls.

(I put extra ones on there so I could exagerate the amount of time it
takes to open a form, so I would see a noticeable difference if I tried
something that was more efficient).

It uses CX components. I've placed a copy of my sample application in
the DBISam Binaries under the subject "Scaling Form Performance for
Roy". I'm not sure if there is a more efficient way to do what I'm
trying to do there.

Cheers

Adam.

Adam

>Agreed. I thought if I have the main thread open the datasets (so I
>don't have any issues with DBISam and threads) and use a second thread
>to do the form loading, visible, scaling, etc that might increase the speed.

DO NOT try and do things with visible controls in a thread whilst I cannot guarantee a problem I know which side of a bet I'd take. If you read in the CodeGear newsgroups you'll see time and time again advice to the effect of visible controls should only be updated in the main thread.

>The main reason I thought this was the comment I read on a upcoming
>Delphi Users Group Conference here in Australia. (Which unfortunately I
>can't attend).
>
>The impression I got is that computers aren't going to get any faster
>any more, but instead are going to have more cores. In order to be able
>to use the extra processing we need to start designing applications with
>multiple threads, simply 'waiting' for a faster computer isn't going to
>work like the old days.

That's probably right. Its reaching the point where higher clock speeds are getting more and more difficult to attain. It seems to be a physical restriction based on the fact that electrons can diffuse through the dividing walls.

>> Assuming my guess about tabbed controls is right then one way threads could be used is if the user is always presented with the same page on opening the form then open the tables/queries necessary for that in the foreground and open the remainder in threads. You'd need to be careful to make queries thread safe when presenting the results back to the user. If you're using memory or temprary tables it would become much easier.
>
>That pretty much happens at the moment. One of the issues I have is the
>amount of 'lookup' queries I have where information is displayed on the
>main page. My current guess is approx 50% form load time, 50% dataset
>opening time. I figured if I could perform both these operations at the
>same time using threads I could effectively halve
>

>The main application will be too difficult to send through to you with
>the amount of 3rd party components that are on there. However I do have
>a test application I made with scaleform (the one that takes ~8 seconds
>to load), but it doesn't have datasets on there. It uses forms that are
>placed onto a pagecontrol. It's loaded with quite a number of cx controls.

And I don't have any of the DevEx components so I can't have a look

However, the DevEx stuff could be the reason that you're having trouble. I bought the TMS components. I still have a number of them on my forms (mainly their page control, glowbutton and stringgrid) and removed their db aware string grid a) because it was awkward to control and b) because it was slow, even when not loading all of the data. If its possible, as a test, try replaceing the DevEx stuff with bog standard components and see what happens. My theory is that the cleverer these components get with more and more functionality the slower they get.

Roy Lambert [Team Elevate]

Adam,

<< On my larger forms with lots of data, both these tasks can take 3+
seconds each to complete their operation making it 6+ seconds for a form to
calculate and display. >>

If you want to send me an example, I can profile it here and see how you can
trim off some time on the database side of things.

As for multi-threading, yes, using multiple threads to enable parallel
execution is something that could help with performance.  However, you have
to keep in mind that the VCL is not multi-threaded, nor are Windows controls
in general.  They both like to stay in the main thread for message
processing and updates, etc.  The database stuff may be improved a bit by
adding threaded execution, but you'll have to contend with the separate
session requirements, which may or may not allow you to do what you want.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim


Updating tables, running queries that do things internal to the thread I can and have done. How would you handle running a query in a thread when you want the result set back in the foreground?

Roy Lambert

Hi Roy,

>> Agreed. I thought if I have the main thread open the datasets (so I
>> don't have any issues with DBISam and threads) and use a second thread
>> to do the form loading, visible, scaling, etc that might increase the speed.
>
> DO NOT try and do things with visible controls in a thread whilst I cannot guarantee a problem I know which side of a bet I'd take. If you read in the CodeGear newsgroups you'll see time and time again advice to the effect of visible controls should only be updated in the main thread.

Thanks for the warning. You've probably saved me some work in finding
this out the hard way!


>> The main application will be too difficult to send through to you with
>> the amount of 3rd party components that are on there. However I do have
>> a test application I made with scaleform (the one that takes ~8 seconds
>> to load), but it doesn't have datasets on there. It uses forms that are
>> placed onto a pagecontrol. It's loaded with quite a number of cx controls.
>
> And I don't have any of the DevEx components so I can't have a look

Dang - sorry about that. If I have the time I may recreate the
application with standard components.

> However, the DevEx stuff could be the reason that you're having trouble. I bought the TMS components. I still have a number of them on my forms (mainly their page control, glowbutton and stringgrid) and removed their db aware string grid a) because it was awkward to control and b) because it was slow, even when not loading all of the data. If its possible, as a test, try replaceing the DevEx stuff with bog standard components and see what happens. My theory is that the cleverer these components get with more and more functionality the slower they get.

I have thought of this too - the DevEx components definitely seem to be
slower than the standard Delphi components. The problem is that I've
used them extensively throughout my application and it would be very
difficult for me to change at this point in time.

That's why I'm looking at alternative options (aka threads) to try and
enhance the performance of my app. But they confuse me, and seem like
there is quite a lot of 'traps' to look out for.

All fun and games.

Cheers

Adam.

Adam



>I have thought of this too - the DevEx components definitely seem to be
>slower than the standard Delphi components. The problem is that I've
>used them extensively throughout my application and it would be very
>difficult for me to change at this point in time.

The massive functionality these types of components offer is very attractive but I think that in much the same way as MS Word (you know its bad when I can type faster than it can display) they have grown to much. All the added functionality has a cost as you're discovering. Even just a boolean test to see if the option is enable has a cost and when there are several hundred of those tests it adds up.

In my case I use DBGrids 99%+ of the time simply to display data not to edit it. Most of the time taken to replace the TMS DB aware grid was taken up in customising Mike Skolnik's freeware DB grid to what I wanted.

Roy Lambert

Roy,

<< Updating tables, running queries that do things internal to the thread I
can and have done. How would you handle running a query in a thread when you
want the result set back in the foreground? >>

Are there any datasets attached to data-aware controls in the main thread ?
If so, then the only safe way is to use:

SaveToStream/LoadFromStream

It's the only safe way to get the data back and forth without issues caused
by two dataset components accessing the same session/database components.

The big issue is Windows refreshing data-aware controls in the main thread,
thus causing concurrent access to the session/database components while the
background thread is still executing.

--
Tim Young
Elevate Software
www.elevatesoft.com

Hi Tim,

Thanks for that. I guess it looks as though there may not be much
performance increase to have for what I'm trying to achieve in using
threads.

If I understand this correctly, the same (visual) components I'm
creating in one thread will be accessing data from another thread, which
effectively need to be loaded into the first/same thread as the visual
components anyway - thus a sequential execution one after the other is
going to need to be done at some point (whether it's the savetostream /
loadfromstream option or something else), thus making the whole point of
using one thread for creating the visual components, and another for the
data components a mute point.

I guess threads are only really going to work when you've got one set of
code to run that's really not directly related to another set.

It's a pitty I can't get to the Melbourne conference - would have been
good to see the talks on threads and see how they can be used in desktop
applications.

Cheers

Adam.