.Net 4.0 Win Forms Caching?
-
Hi all, I have a scenario that is puzzling me and I'm guessing at the behavior and was wondering if anyone else knew what was happening under the skin of .Net. I have a .Net 4.0 application on a clients' Windows Server 2008 64bit back end database is an ALPHA (not relevant). The application is 1 form with literally hundreds of controls on it and also an image viewer. It's takes up quite a bit of screen space, and has multiple tabs (at least 8) to hold all the controls. The puzzling scenario is this: 1. Open up a simple list 2. Select an item from the list to open up the form as described above - this takes over 1min 15secs 2. Close the form (return to list in point 1) 3. Open up the same form from the list loading the controls in exactly the same way with the same queries behind it (assuming not relevant from the logs I've looked at), and it can open in 10 seconds flat. From the looks of the memory print in Task Manager, the memory obviously shoots up when the form is first opened, but doesn't go down too far after closing the form. On reopening the form again, the memory doesn't go up much but only takes 10 seconds to open. I'm thinking that .Net is loading up a load of stuff (!for want of a better word!) into memory on first load of form, and subsequent forms use what has previously been loaded into memory. If it's not this that is happening, I'm not sure what is happening, as I have been asked by our client to try and make the first load of the form as quick as each subsequent one, and not sure if this is indeed possible. Any light shed on this would be most appreciated. Many thanks Julian
-
Hi all, I have a scenario that is puzzling me and I'm guessing at the behavior and was wondering if anyone else knew what was happening under the skin of .Net. I have a .Net 4.0 application on a clients' Windows Server 2008 64bit back end database is an ALPHA (not relevant). The application is 1 form with literally hundreds of controls on it and also an image viewer. It's takes up quite a bit of screen space, and has multiple tabs (at least 8) to hold all the controls. The puzzling scenario is this: 1. Open up a simple list 2. Select an item from the list to open up the form as described above - this takes over 1min 15secs 2. Close the form (return to list in point 1) 3. Open up the same form from the list loading the controls in exactly the same way with the same queries behind it (assuming not relevant from the logs I've looked at), and it can open in 10 seconds flat. From the looks of the memory print in Task Manager, the memory obviously shoots up when the form is first opened, but doesn't go down too far after closing the form. On reopening the form again, the memory doesn't go up much but only takes 10 seconds to open. I'm thinking that .Net is loading up a load of stuff (!for want of a better word!) into memory on first load of form, and subsequent forms use what has previously been loaded into memory. If it's not this that is happening, I'm not sure what is happening, as I have been asked by our client to try and make the first load of the form as quick as each subsequent one, and not sure if this is indeed possible. Any light shed on this would be most appreciated. Many thanks Julian
My initial thought here, as you haven't said what database you are hitting, is that the database connection is being pooled. On the first invocation, the connection is being created which is a time consuming process. Further invocations are able to take the pooled database connection. You are also correct that the .NET runtime will also grab extra memory which is not released immediately, allowing space for the application to load the form in again.
*pre-emptive celebratory nipple tassle jiggle* - Sean Ewington
"Mind bleach! Send me mind bleach!" - Nagy Vilmos
My blog | My articles | MoXAML PowerToys | Mole 2010 - debugging made easier - my favourite utility
-
Hi all, I have a scenario that is puzzling me and I'm guessing at the behavior and was wondering if anyone else knew what was happening under the skin of .Net. I have a .Net 4.0 application on a clients' Windows Server 2008 64bit back end database is an ALPHA (not relevant). The application is 1 form with literally hundreds of controls on it and also an image viewer. It's takes up quite a bit of screen space, and has multiple tabs (at least 8) to hold all the controls. The puzzling scenario is this: 1. Open up a simple list 2. Select an item from the list to open up the form as described above - this takes over 1min 15secs 2. Close the form (return to list in point 1) 3. Open up the same form from the list loading the controls in exactly the same way with the same queries behind it (assuming not relevant from the logs I've looked at), and it can open in 10 seconds flat. From the looks of the memory print in Task Manager, the memory obviously shoots up when the form is first opened, but doesn't go down too far after closing the form. On reopening the form again, the memory doesn't go up much but only takes 10 seconds to open. I'm thinking that .Net is loading up a load of stuff (!for want of a better word!) into memory on first load of form, and subsequent forms use what has previously been loaded into memory. If it's not this that is happening, I'm not sure what is happening, as I have been asked by our client to try and make the first load of the form as quick as each subsequent one, and not sure if this is indeed possible. Any light shed on this would be most appreciated. Many thanks Julian
Assuming your description of the situation is somewhat accurate, I can only conclude one did a few things wrongly in the implementation. Adding some simple logging (with time stamps obviously) to the app would allow to pinpoint the major problems. And yes I expect there to be more than one. To name some candidates: - user authorization on the network - user authorization on the DB - establishing the first DB connection - building the GUI - obtaining all the data - stuffing the data in the GUI. You'll need some facts before you can effectively tackle this, so start logging! Alternatively, and maybe harder to implement and interpret, try simpler set-ups. BTW: your app may or may not contain extra implementation features to make subsequent operations faster, think caching. The more of these you have, the more impossible it should become for the first operation to be as fast as subsequent ones. FWIW: In Windows, dialog windows can be hidden and shown over and over, without recreating them. So even the most complex dialog could be shown again in a fraction of a second (and anyone can come up with ways to make things slower). PS: if you have tab pages on a Form, then there is no need to fully populate them all before showing anything to the user, as he can see only one of them at a time. The right approach would be to either load the others in a lazy way, i.e. only when needed; or in a background operation, i.e. after the essential work has finished. :)
Luc Pattyn [My Articles] Nil Volentibus Arduum
-
Assuming your description of the situation is somewhat accurate, I can only conclude one did a few things wrongly in the implementation. Adding some simple logging (with time stamps obviously) to the app would allow to pinpoint the major problems. And yes I expect there to be more than one. To name some candidates: - user authorization on the network - user authorization on the DB - establishing the first DB connection - building the GUI - obtaining all the data - stuffing the data in the GUI. You'll need some facts before you can effectively tackle this, so start logging! Alternatively, and maybe harder to implement and interpret, try simpler set-ups. BTW: your app may or may not contain extra implementation features to make subsequent operations faster, think caching. The more of these you have, the more impossible it should become for the first operation to be as fast as subsequent ones. FWIW: In Windows, dialog windows can be hidden and shown over and over, without recreating them. So even the most complex dialog could be shown again in a fraction of a second (and anyone can come up with ways to make things slower). PS: if you have tab pages on a Form, then there is no need to fully populate them all before showing anything to the user, as he can see only one of them at a time. The right approach would be to either load the others in a lazy way, i.e. only when needed; or in a background operation, i.e. after the essential work has finished. :)
Luc Pattyn [My Articles] Nil Volentibus Arduum
Hi Yep, already logging like crazy. I have 2 logs on the go, Log1: almost every function logs it's 'In' and 'Out' times in milliseconds Log2: Every single query performed on the database is logged to a separate file and time stamped. I can see from the combination of these what takes time. So I can see for instance that the Form Shown event finishes at time x (on first showing), and the form doesn't actually appear on the screen until 30 seconds later. Also, no queries occur or other functions called during that 30 seconds. The database connection (as stated, an Alpha database running on a VMS server) is never dropped, it is continually open and open before the form is first constructed. Untangling the data from the tabs would be too time consuming (showing data as needed), and we would be issuing queries multiple times, when it would only need to be once at the beginning. However I have taken this approach with the second tab control (there are 2 on the form - 1 with 1 image per tab, and 1 with controls on each tab). The image tab control does indeed load it's image only when necessary as image handling can take time. I think it's too late to re-show the dialog and simply re-populate the controls on showing the second time, and the second time isn't a problem anyway. I'm also using threads to help populate the form, attempting as best as possible to do many things at one time. So, still not sure. Julian
-
My initial thought here, as you haven't said what database you are hitting, is that the database connection is being pooled. On the first invocation, the connection is being created which is a time consuming process. Further invocations are able to take the pooled database connection. You are also correct that the .NET runtime will also grab extra memory which is not released immediately, allowing space for the application to load the form in again.
*pre-emptive celebratory nipple tassle jiggle* - Sean Ewington
"Mind bleach! Send me mind bleach!" - Nagy Vilmos
My blog | My articles | MoXAML PowerToys | Mole 2010 - debugging made easier - my favourite utility
Hi The connection to the database is active before the form loads, and is not dropped for the duration of the application lifetime (it's a secure self contained network). The database as stated is an Alpha database running on a VMS server. We have a windows dll interface to it. I'm interested in your point about .Net not releasing memory. If I create a new Form each time (Form1 creating Form2 - Form2 being the Form in question), do you think that .Net will intelligently store stuff it needs and call on it again when I create a new Form2? Thanks for your response Julian
-
Hi Yep, already logging like crazy. I have 2 logs on the go, Log1: almost every function logs it's 'In' and 'Out' times in milliseconds Log2: Every single query performed on the database is logged to a separate file and time stamped. I can see from the combination of these what takes time. So I can see for instance that the Form Shown event finishes at time x (on first showing), and the form doesn't actually appear on the screen until 30 seconds later. Also, no queries occur or other functions called during that 30 seconds. The database connection (as stated, an Alpha database running on a VMS server) is never dropped, it is continually open and open before the form is first constructed. Untangling the data from the tabs would be too time consuming (showing data as needed), and we would be issuing queries multiple times, when it would only need to be once at the beginning. However I have taken this approach with the second tab control (there are 2 on the form - 1 with 1 image per tab, and 1 with controls on each tab). The image tab control does indeed load it's image only when necessary as image handling can take time. I think it's too late to re-show the dialog and simply re-populate the controls on showing the second time, and the second time isn't a problem anyway. I'm also using threads to help populate the form, attempting as best as possible to do many things at one time. So, still not sure. Julian
julian@giant wrote:
he form doesn't actually appear on the screen until 30 seconds later.
That is unacceptable, and I've never seen such thing.
julian@giant wrote:
The database connection (as stated, an Alpha database running on a VMS server) is never dropped
That sounds wrong. You should not keep connections open, .NET has connection pooling, meaning you open-query-close (actually use the using construct for getting a connection), and .NET will silently cache and reuse connections for you. With only one connection, you are preventing efficient multi-threading to the DB.
julian@giant wrote:
I'm also using threads to help populate the form
I know of many ways to get that wrong. Too many thread switches would be one; deadlocks another. Are you using Control.InvokeRequired/Control.Invoke? Are you overusing them for each little piece of displayable information? And please don't tell me you have touched Control.CheckForIllegalCrossThreadCalls! Suggestion: use Task Manager and watch your client's CPU load; if it is near zero for several seconds, something is very wrong (deadlock suspected); if it is near 1/N (with N cores), a busy loop may be the culprit. Also have a look at your server's CPU load (assuming you can get your client to be the only client). Can you correlate both load curves? Any dead periods overall? PS: no, .NET isn't caching anything in general, when it does, it is documented. DB connections is an example. Windows does cache files. And .NET is not throwing away things as long as it doesn't need the memory for something else. However a new Form would be independent of a previous instance of the same Form (except for its code to be loaded and JIT-ted just once). :)
Luc Pattyn [My Articles] Nil Volentibus Arduum
-
Hi Yep, already logging like crazy. I have 2 logs on the go, Log1: almost every function logs it's 'In' and 'Out' times in milliseconds Log2: Every single query performed on the database is logged to a separate file and time stamped. I can see from the combination of these what takes time. So I can see for instance that the Form Shown event finishes at time x (on first showing), and the form doesn't actually appear on the screen until 30 seconds later. Also, no queries occur or other functions called during that 30 seconds. The database connection (as stated, an Alpha database running on a VMS server) is never dropped, it is continually open and open before the form is first constructed. Untangling the data from the tabs would be too time consuming (showing data as needed), and we would be issuing queries multiple times, when it would only need to be once at the beginning. However I have taken this approach with the second tab control (there are 2 on the form - 1 with 1 image per tab, and 1 with controls on each tab). The image tab control does indeed load it's image only when necessary as image handling can take time. I think it's too late to re-show the dialog and simply re-populate the controls on showing the second time, and the second time isn't a problem anyway. I'm also using threads to help populate the form, attempting as best as possible to do many things at one time. So, still not sure. Julian
If I were you, I'd be looking into using an application profiler to see where the time is being taken up. It will make your life a lot easier because it will enable you to see what your application is really doing - look particularly for excessively long calls for few calls, or operations with excessive number of calls.
*pre-emptive celebratory nipple tassle jiggle* - Sean Ewington
"Mind bleach! Send me mind bleach!" - Nagy Vilmos
My blog | My articles | MoXAML PowerToys | Mole 2010 - debugging made easier - my favourite utility
-
julian@giant wrote:
he form doesn't actually appear on the screen until 30 seconds later.
That is unacceptable, and I've never seen such thing.
julian@giant wrote:
The database connection (as stated, an Alpha database running on a VMS server) is never dropped
That sounds wrong. You should not keep connections open, .NET has connection pooling, meaning you open-query-close (actually use the using construct for getting a connection), and .NET will silently cache and reuse connections for you. With only one connection, you are preventing efficient multi-threading to the DB.
julian@giant wrote:
I'm also using threads to help populate the form
I know of many ways to get that wrong. Too many thread switches would be one; deadlocks another. Are you using Control.InvokeRequired/Control.Invoke? Are you overusing them for each little piece of displayable information? And please don't tell me you have touched Control.CheckForIllegalCrossThreadCalls! Suggestion: use Task Manager and watch your client's CPU load; if it is near zero for several seconds, something is very wrong (deadlock suspected); if it is near 1/N (with N cores), a busy loop may be the culprit. Also have a look at your server's CPU load (assuming you can get your client to be the only client). Can you correlate both load curves? Any dead periods overall? PS: no, .NET isn't caching anything in general, when it does, it is documented. DB connections is an example. Windows does cache files. And .NET is not throwing away things as long as it doesn't need the memory for something else. However a new Form would be independent of a previous instance of the same Form (except for its code to be loaded and JIT-ted just once). :)
Luc Pattyn [My Articles] Nil Volentibus Arduum
Hi Luc Thanks. Yes I agree, 30 seconds is totally unacceptable! And strange. I'm trying to find out what's causing it now. On the face of it, the program is not doing anything! But I do see the server memory going up and up during that 30 seconds. The database connection thing has been the way the company does things for along time. I've tried a separate app that does indeed do what you're suggesting (putting queries in threads etc.), but somehow, the Alpha database (it came out of the Ark) can't handle queries being done on threads other than the main thread. So, I've stuck with one connection. I'm pretty sure there's no threading issue during that 30 seconds, but it's something i will check. Thanks again for your response. Julian
-
If I were you, I'd be looking into using an application profiler to see where the time is being taken up. It will make your life a lot easier because it will enable you to see what your application is really doing - look particularly for excessively long calls for few calls, or operations with excessive number of calls.
*pre-emptive celebratory nipple tassle jiggle* - Sean Ewington
"Mind bleach! Send me mind bleach!" - Nagy Vilmos
My blog | My articles | MoXAML PowerToys | Mole 2010 - debugging made easier - my favourite utility
Thanks Pete, that's a good idea, I'll see what I can do. Cheers Julian
-
Hi Luc Thanks. Yes I agree, 30 seconds is totally unacceptable! And strange. I'm trying to find out what's causing it now. On the face of it, the program is not doing anything! But I do see the server memory going up and up during that 30 seconds. The database connection thing has been the way the company does things for along time. I've tried a separate app that does indeed do what you're suggesting (putting queries in threads etc.), but somehow, the Alpha database (it came out of the Ark) can't handle queries being done on threads other than the main thread. So, I've stuck with one connection. I'm pretty sure there's no threading issue during that 30 seconds, but it's something i will check. Thanks again for your response. Julian
if that 30 seconds is wasted on the server's side (and memory is spent more than expected?), it tells me either your query is awful, or your DB is performing some silly tasks such as say "dynamic indexing". Check your query, and the indexes that are in place. But then you said the 30 seconds elapsed between the end of Shown and the Form appearing? There should be nothing there, in fact a Form normally is visible when the Shown handler begins. I'm not convinced yet all your observations are correct (I learned long ago to suspect everything while debugging and/or hunting for performance). :)
Luc Pattyn [My Articles] Nil Volentibus Arduum
-
julian@giant wrote:
he form doesn't actually appear on the screen until 30 seconds later.
That is unacceptable, and I've never seen such thing.
julian@giant wrote:
The database connection (as stated, an Alpha database running on a VMS server) is never dropped
That sounds wrong. You should not keep connections open, .NET has connection pooling, meaning you open-query-close (actually use the using construct for getting a connection), and .NET will silently cache and reuse connections for you. With only one connection, you are preventing efficient multi-threading to the DB.
julian@giant wrote:
I'm also using threads to help populate the form
I know of many ways to get that wrong. Too many thread switches would be one; deadlocks another. Are you using Control.InvokeRequired/Control.Invoke? Are you overusing them for each little piece of displayable information? And please don't tell me you have touched Control.CheckForIllegalCrossThreadCalls! Suggestion: use Task Manager and watch your client's CPU load; if it is near zero for several seconds, something is very wrong (deadlock suspected); if it is near 1/N (with N cores), a busy loop may be the culprit. Also have a look at your server's CPU load (assuming you can get your client to be the only client). Can you correlate both load curves? Any dead periods overall? PS: no, .NET isn't caching anything in general, when it does, it is documented. DB connections is an example. Windows does cache files. And .NET is not throwing away things as long as it doesn't need the memory for something else. However a new Form would be independent of a previous instance of the same Form (except for its code to be loaded and JIT-ted just once). :)
Luc Pattyn [My Articles] Nil Volentibus Arduum
Luc Pattyn wrote:
he form doesn't actually appear on the screen until 30 seconds later.
That is unacceptable, and I've never seen such thing.
I have. When there's hundred of controls on the form. Creating a control, and the underying window, is expensive. Then, if he's populating list controls with hundreds of items, that isn't exactly setting an speed records either.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak -
if that 30 seconds is wasted on the server's side (and memory is spent more than expected?), it tells me either your query is awful, or your DB is performing some silly tasks such as say "dynamic indexing". Check your query, and the indexes that are in place. But then you said the 30 seconds elapsed between the end of Shown and the Form appearing? There should be nothing there, in fact a Form normally is visible when the Shown handler begins. I'm not convinced yet all your observations are correct (I learned long ago to suspect everything while debugging and/or hunting for performance). :)
Luc Pattyn [My Articles] Nil Volentibus Arduum
Thanks Luc, You've helped me identify some places to look and I shall double check the Form Show event. Don't think that the database has anything to do with it, we issue a query and it comes back, (some take longer than others) but I've never experienced a query to the DB causing a hang of sorts after it has returned. That's not to say it isn't a first. The DB as I say is old and the interface to it seems to be not overly supported. Thinking about it, that is an area i haven't looked into. Time to investigate the Alpha logs.. oh no... save me.... Cheers Julian
-
Luc Pattyn wrote:
he form doesn't actually appear on the screen until 30 seconds later.
That is unacceptable, and I've never seen such thing.
I have. When there's hundred of controls on the form. Creating a control, and the underying window, is expensive. Then, if he's populating list controls with hundreds of items, that isn't exactly setting an speed records either.
A guide to posting questions on CodeProject[^]
Dave KreskowiakThanks Dave. I am indeed populating many DataGridViews, which at this point should have been loaded with their data. Not hundreds of rows per DGV tho. I'll bear it in mind. Cheers Julian
-
Luc Pattyn wrote:
he form doesn't actually appear on the screen until 30 seconds later.
That is unacceptable, and I've never seen such thing.
I have. When there's hundred of controls on the form. Creating a control, and the underying window, is expensive. Then, if he's populating list controls with hundreds of items, that isn't exactly setting an speed records either.
A guide to posting questions on CodeProject[^]
Dave KreskowiakI agree having lots of Controls isn't a great idea, however I do expect Shown to be true to its name, especially as the Controls should all be created by the main thread which is also where the Shown handler is running. So I'd expect a complete Paint to have finished before Shown fires. You're saying that is not guaranteed? [ADDED] I just performed a little experiment, with a Form's Load handler adding 5000 labels. The Load handler took over 20 seconds, the Shown handler sounded its programmed beep when the Form became visible. And the first Paint event came right after the Shown event, not before! So Windows claims a Form is shown without it being painted?? [/ADDED] :)
Luc Pattyn [My Articles] Nil Volentibus Arduum
-
Hi all, I have a scenario that is puzzling me and I'm guessing at the behavior and was wondering if anyone else knew what was happening under the skin of .Net. I have a .Net 4.0 application on a clients' Windows Server 2008 64bit back end database is an ALPHA (not relevant). The application is 1 form with literally hundreds of controls on it and also an image viewer. It's takes up quite a bit of screen space, and has multiple tabs (at least 8) to hold all the controls. The puzzling scenario is this: 1. Open up a simple list 2. Select an item from the list to open up the form as described above - this takes over 1min 15secs 2. Close the form (return to list in point 1) 3. Open up the same form from the list loading the controls in exactly the same way with the same queries behind it (assuming not relevant from the logs I've looked at), and it can open in 10 seconds flat. From the looks of the memory print in Task Manager, the memory obviously shoots up when the form is first opened, but doesn't go down too far after closing the form. On reopening the form again, the memory doesn't go up much but only takes 10 seconds to open. I'm thinking that .Net is loading up a load of stuff (!for want of a better word!) into memory on first load of form, and subsequent forms use what has previously been loaded into memory. If it's not this that is happening, I'm not sure what is happening, as I have been asked by our client to try and make the first load of the form as quick as each subsequent one, and not sure if this is indeed possible. Any light shed on this would be most appreciated. Many thanks Julian
How large is the ViewState becoming, i remember a way back i was doing something stupid and i had ended up having a ViewState that was almost 10MB... i had to remove the control i was using as a table cell on a large table page and refactor it was painfull
-
I agree having lots of Controls isn't a great idea, however I do expect Shown to be true to its name, especially as the Controls should all be created by the main thread which is also where the Shown handler is running. So I'd expect a complete Paint to have finished before Shown fires. You're saying that is not guaranteed? [ADDED] I just performed a little experiment, with a Form's Load handler adding 5000 labels. The Load handler took over 20 seconds, the Shown handler sounded its programmed beep when the Form became visible. And the first Paint event came right after the Shown event, not before! So Windows claims a Form is shown without it being painted?? [/ADDED] :)
Luc Pattyn [My Articles] Nil Volentibus Arduum
Thanks Luc. I'll give that a go myself but spark off the form from another form, and try it a second time and see if it takes just as long on the second time. Interesting. Cheers Julian
-
How large is the ViewState becoming, i remember a way back i was doing something stupid and i had ended up having a ViewState that was almost 10MB... i had to remove the control i was using as a table cell on a large table page and refactor it was painfull
Windows Forms don't use ViewState. You're getting confused into thinking the OP was talking about ASP.NET.
*pre-emptive celebratory nipple tassle jiggle* - Sean Ewington
"Mind bleach! Send me mind bleach!" - Nagy Vilmos
My blog | My articles | MoXAML PowerToys | Mole 2010 - debugging made easier - my favourite utility
-
Windows Forms don't use ViewState. You're getting confused into thinking the OP was talking about ASP.NET.
*pre-emptive celebratory nipple tassle jiggle* - Sean Ewington
"Mind bleach! Send me mind bleach!" - Nagy Vilmos
My blog | My articles | MoXAML PowerToys | Mole 2010 - debugging made easier - my favourite utility
Phew, thanks Pete, thought I was missing something there.... :)
-
Phew, thanks Pete, thought I was missing something there.... :)
No problem. I had to check which post it was replying to beforehand.
*pre-emptive celebratory nipple tassle jiggle* - Sean Ewington
"Mind bleach! Send me mind bleach!" - Nagy Vilmos
My blog | My articles | MoXAML PowerToys | Mole 2010 - debugging made easier - my favourite utility
-
Hi all, I have a scenario that is puzzling me and I'm guessing at the behavior and was wondering if anyone else knew what was happening under the skin of .Net. I have a .Net 4.0 application on a clients' Windows Server 2008 64bit back end database is an ALPHA (not relevant). The application is 1 form with literally hundreds of controls on it and also an image viewer. It's takes up quite a bit of screen space, and has multiple tabs (at least 8) to hold all the controls. The puzzling scenario is this: 1. Open up a simple list 2. Select an item from the list to open up the form as described above - this takes over 1min 15secs 2. Close the form (return to list in point 1) 3. Open up the same form from the list loading the controls in exactly the same way with the same queries behind it (assuming not relevant from the logs I've looked at), and it can open in 10 seconds flat. From the looks of the memory print in Task Manager, the memory obviously shoots up when the form is first opened, but doesn't go down too far after closing the form. On reopening the form again, the memory doesn't go up much but only takes 10 seconds to open. I'm thinking that .Net is loading up a load of stuff (!for want of a better word!) into memory on first load of form, and subsequent forms use what has previously been loaded into memory. If it's not this that is happening, I'm not sure what is happening, as I have been asked by our client to try and make the first load of the form as quick as each subsequent one, and not sure if this is indeed possible. Any light shed on this would be most appreciated. Many thanks Julian
If you want your application to speed up. The first place you need to look at is the database design. Partition it into smaller table for query speed. ______________________________________________________________________________ Easy fast local ads Listing for free at 4sellpage.com
charliezcr