.Net 4.0 Win Forms Caching?
-
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
-
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
I just tried the same, with similar results. I added 5000 labels to the form, each with a different x/y position. Took about 20 seconds before they displayed. Then I tried resizing the form and I could actually see the labels repainting over several seconds. The problem in this case seems to be a very inefficient repaint algorithm. Probably something like an O(N^2) inefficiency. I've seen this before when I implemented a repaint algorithm for a 2D game that found the top rectangle, painted it, then recursively descended down the 8 surrounding quadrants to check the remaining rectangles. With enough rectangles, it becomes more efficient to just draw all of the rectangles in their entirety, from bottom to top. I think the game Sonic had this problem too... if you get a bunch of rings on the screen at the same time, the animation will slow down. :) Pretty amazing that such an inefficiency exists in Windows Forms.
-
I just tried the same, with similar results. I added 5000 labels to the form, each with a different x/y position. Took about 20 seconds before they displayed. Then I tried resizing the form and I could actually see the labels repainting over several seconds. The problem in this case seems to be a very inefficient repaint algorithm. Probably something like an O(N^2) inefficiency. I've seen this before when I implemented a repaint algorithm for a 2D game that found the top rectangle, painted it, then recursively descended down the 8 surrounding quadrants to check the remaining rectangles. With enough rectangles, it becomes more efficient to just draw all of the rectangles in their entirety, from bottom to top. I think the game Sonic had this problem too... if you get a bunch of rings on the screen at the same time, the animation will slow down. :) Pretty amazing that such an inefficiency exists in Windows Forms.
-
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
Thanks for your input charliezcr. I don't have a problem with the queries. I'm logging all the queries I'm doing and can see how long each one takes. they are all normal. I am exploring other avenues at the moment whilst looking at another part of the code, so don't worry. Thanks Julian
-
AspDotNetDev wrote:
The problem in this case seems to be a very inefficient repaint algorithm.
Lot's of handle's means lot's of communication. Easily remedied; stop using that ridiculous amount of controls.
Bastard Programmer from Hell :suss:
Um... thanks for that Eddy, but what if your Dialog requires lots of controls? J
-
Um... thanks for that Eddy, but what if your Dialog requires lots of controls? J
Lots of controls means lots of message-pumps. Now, instead of creating 300 checkboxes and stacking them, one could draw 300 checkboxes on a single control. Then you catch the mouseclicks on your panel, and check/uncheck that checkbox manually, and update the drawing. That eliminates 299 message pumps, and some handles.
Bastard Programmer from Hell :suss:
-
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
OK, have now got this sorted. Previously the .exe I was doing performance enhancements on was 450Mb in size and took 1m30s to load each form it needed to create (from within the app itself)! I managed to get this down to 1m15s on the first time the form was opened and 10 seconds every subsequent time it was opened from within the app. Memory usage was down to 150Mb. I was quite pleased with myself. The target application server is 64bit. Setting the target CPU in the project settings of the application to x86 from x64 brought the size of the .exe down to around 60Mb and there is no delay on the initial creation of the first form from within the app. Knew I'd get there in the end. Thanks for all your input into this guys. Some most interesting suggestions. Cheers Julian
-
OK, have now got this sorted. Previously the .exe I was doing performance enhancements on was 450Mb in size and took 1m30s to load each form it needed to create (from within the app itself)! I managed to get this down to 1m15s on the first time the form was opened and 10 seconds every subsequent time it was opened from within the app. Memory usage was down to 150Mb. I was quite pleased with myself. The target application server is 64bit. Setting the target CPU in the project settings of the application to x86 from x64 brought the size of the .exe down to around 60Mb and there is no delay on the initial creation of the first form from within the app. Knew I'd get there in the end. Thanks for all your input into this guys. Some most interesting suggestions. Cheers Julian
Thanks for the update. I have no idea why a target change would have such drastic effects. Do you? Or what haven't you told us?? :)
Luc Pattyn [My Articles] Nil Volentibus Arduum
-
Thanks for the update. I have no idea why a target change would have such drastic effects. Do you? Or what haven't you told us?? :)
Luc Pattyn [My Articles] Nil Volentibus Arduum
I don't know what I haven't told you .... yet.... :)