Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 8 of 8 total
Thread Performance Tuning for Internet Access
Wed, Jul 12 2006 8:54 PMPermanent Link

"Johnnie Norsworthy"
Howdy all!

My application works great on a local area network, but less than desirable
when running across the internet. I have done all the tricks I can think of
and I have read about here to speed things up.

The first thing I do is run a query and use Query.SaveToStream and then
Table.LoadFromStream with the table saved as a local memory table. This
makes the DevExpress quantum grids in "Load All Records" mode work great. I
get a few hundred records in the grid in about 10 seconds across the
internet which is completely acceptable.

But the problem I have now that is bogging me down is that the grid table
functions like a master table and when a selection in the grid changes, I
change some filters for a few detail tables. I am using a TTimer to start
the detail synchronization about .5 seconds after a master record focus
changes. The problem is, the changing of the detail table filters is taking
a very long time (5 seconds or more each time) and the program seems very
unresponsive.

Does anyone have similar circumstances and have come up with a solution?
Threads? Application.OnIdle? I don't know where to start for testing what
will work best.

On a local area network the application screams along at what I like to call
"keyboard repeat rate" responsive. (That is you can hold down the arrow key
and it never hiccups).

I am hoping on borrowing some superior wisdom of the DBISAM Community.

-Johnnie

Thu, Jul 13 2006 12:43 PMPermanent Link

"David Farrell-Garcia"
I use ClientDataSets to cache all the data on the local machine.  I
then have no latency when scrolling grids with Detail Records.  Lookup
tables are saved to local .cds tables so even lookup fields work great.
Thu, Jul 13 2006 2:13 PMPermanent Link

"Johnnie Norsworthy"
"David Farrell-Garcia" <davidF@WhidbeyIslandSoftware.com> wrote in message
news:D993A5CB-1412-48B2-9DA2-FD8EBB828CE0@news.elevatesoft.com...
>I use ClientDataSets to cache all the data on the local machine.  I
> then have no latency when scrolling grids with Detail Records.  Lookup
> tables are saved to local .cds tables so even lookup fields work great.

I cache the grid data and lookups, but I can't cache all of the detail data
because there is too much, and I'd like the detail data to reflect changes
made by others.

-Johnnie

Thu, Jul 13 2006 10:39 PMPermanent Link

"David Farrell-Garcia"
Johnnie Norsworthy wrote:

> I cache the grid data and lookups, but I can't cache all of the
> detail data because there is too much, and I'd like the detail data
> to reflect changes made by others.

How much detail per master record are we talking about?  In my case I
have work orders that may have several to hundreds of detail line
items.  When viewing a selected list of work orders (Master) the
details are only fetched when the user chooses to do so by clicking on
a detail tab.  Then all detail records for that master record are
fetched and cached. This is a better user experience then fetching the
details automatiaclly when a user scrolls a grid.
Thu, Jul 13 2006 10:42 PMPermanent Link

"David Farrell-Garcia"
Johnnie, I forgot to ask:

I assume that you are using a higher compression level for Internet
connections, right?
Fri, Jul 14 2006 3:19 PMPermanent Link

"Johnnie Norsworthy"
"David Farrell-Garcia" <davidF@WhidbeyIslandSoftware.com> wrote in message
news:EB71341B-FA43-4F6D-AAF7-FDC97D110DE7@news.elevatesoft.com...
> Johnnie Norsworthy wrote:
>
>> I cache the grid data and lookups, but I can't cache all of the
>> detail data because there is too much, and I'd like the detail data
>> to reflect changes made by others.
>
> How much detail per master record are we talking about?  In my case I
> have work orders that may have several to hundreds of detail line
> items.  When viewing a selected list of work orders (Master) the
> details are only fetched when the user chooses to do so by clicking on
> a detail tab.  Then all detail records for that master record are
> fetched and cached. This is a better user experience then fetching the
> details automatiaclly when a user scrolls a grid.

They are just used to the details appearing as they scroll, and there are a
bunch of DB-Aware visual controls being displayed including a second detail
grid, but I might make a UI change only when connected remotely to not give
all the details.

I haven't tried the compression yet (slaps head). I'll have to do some
timings with different compression settings and see what I get.

Thanks,
Johnnie

Sun, Jul 23 2006 3:50 PMPermanent Link

"Rob Frye"
Hi Johnnie

I have the same problem (ie. multiple detail tables that have to stay
in sync with the master).  Have you had any luck resolving it?

Rob

"Johnnie Norsworthy" <jln206@verizon.net> wrote in message
news:9AFAD573-FFAC-45BE-88C1-09E93A0BE6A6@news.elevatesoft.com...
> But the problem I have now that is bogging me down is that the grid table
> functions like a master table and when a selection in the grid changes, I
> change some filters for a few detail tables. I am using a TTimer to start
> the detail synchronization about .5 seconds after a master record focus
> changes. The problem is, the changing of the detail table filters is
> taking a very long time (5 seconds or more each time) and the program
> seems very unresponsive.

Sun, Jul 23 2006 4:00 PMPermanent Link

"Johnnie Norsworthy"
"Rob Frye" <rfrye@telus.net> wrote in message
news:096C482D-7F3A-45E6-8F20-B045A69482B7@news.elevatesoft.com...
> Hi Johnnie
>
> I have the same problem (ie. multiple detail tables that have to stay
> in sync with the master).  Have you had any luck resolving it?

Not really solved yet. I have a couple of ideas in mind:

I was thinking about doing was creating a low priority thread which would
update the detail information. I have not figured out all the necessities of
that because the thread would be an observer and would have to be able to
immedietly restart if the master record changed, as in fast grid scrolling.
I like this idea, but haven't tried the implementation yet.

The other option I have considered is detaching all detail tables until the
user wants to view them, but only for internet connections since LAN
connections are fast. In my case the details are displayed on a page
control, so I could set it up to only request the data for the currently
displayed page. Lots of complexity here too.

I already have cached all my grid data from the server into a local memory
table, which seems to help a tiny bit.

-Johnnie


> "Johnnie Norsworthy" <jln206@verizon.net> wrote in message
> news:9AFAD573-FFAC-45BE-88C1-09E93A0BE6A6@news.elevatesoft.com...
>> But the problem I have now that is bogging me down is that the grid table
>> functions like a master table and when a selection in the grid changes, I
>> change some filters for a few detail tables. I am using a TTimer to start
>> the detail synchronization about .5 seconds after a master record focus
>> changes. The problem is, the changing of the detail table filters is
>> taking a very long time (5 seconds or more each time) and the program
>> seems very unresponsive.
>
>

Image