|
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).
|
|
|
|
|
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
|
|
|
|
|
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??
|
|
|
|
|
I don't know what I haven't told you .... yet....
|
|
|
|
|
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.
|
|
|
|
|
Thanks 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
|
|
|
|
|
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]
|
|
|
|
|
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
modified 17-Feb-12 5:06am.
|
|
|
|
|
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.
|
|
|
|
|
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 
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
Thanks Pete, that's a good idea, I'll see what I can do.
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.
|
|
|
|
|
Phew, thanks Pete, thought I was missing something there....
|
|
|
|
|
No problem. I had to check which post it was replying to beforehand.
|
|
|
|
|
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
|
|
|
|
|
I am currently trying to call multiple wcf services under a single transaction scope and got the following exception :
System.ServiceModel.CommunicationException: The maximum retry count has been exc
eeded with no response from the remote endpoint. The reliable session was faulte
d. This is often an indication that the remote endpoint is no longer available.
My client and service are using wsHttpBinding with the endpoint used in the operation. The service operation are both update operations performed on an Oracle database (10g) using ODP.Net (11g). My client and service are both running on my local machine and MSDTC is properly configured on it (I figure it is because I'm able to monitor transactions that are enlisted during service call).
To be more specific, The exception is cut on the second call to the endpoint (the same endpoint in both call)s. The first operation is a simple update witch doesn't requires a lot of time to perform, on the other hand, the second operation, is more consuming (about a minute to perform). Without a transaction, both operations are working fine (but it is not a viable long term solution).
I got success performing multiple service call to simple database operation. The transaction works fine and completes. But it seems that, when I call a service that requires more processing, the problem happens.
Here is the binding that I use :
<wsHttpBinding>
<binding name="WSHttpBinding_Provider" closeTimeout="00:01:00" openTimeout="00:10:00" receiveTimeout="00:10:00" sendTimeout="00:10:00"
bypassProxyOnLocal="false" transactionFlow="true" hostNameComparisonMode="StrongWildcard" maxBufferPoolSize="2147483647"
maxReceivedMessageSize="200000000" messageEncoding="Text" textEncoding="utf-8" useDefaultWebProxy="true" allowCookies="false">
<readerQuotas maxDepth="2147483647" maxStringContentLength="2147483647" maxArrayLength="2147483647" maxBytesPerRead="2147483647" maxNameTableCharCount="2147483647" />
<reliableSession ordered="true" inactivityTimeout="00:20:00" enabled="true"/>
<security mode="None">
<transport clientCredentialType="Windows" proxyCredentialType="None" realm="" />
<message clientCredentialType="Windows" negotiateServiceCredential="true" algorithmSuite="Default" establishSecurityContext="true" />
</security>
</binding>
</wsHttpBinding>
Here is my Oracle connection string :
connectionString="DATA SOURCE=LPRG;USER ID=/;pooling=true;PROMOTABLE TRANSACTION=promotable; Enlist=true"
I have tried ws2007HttpBinding and got the same issued. It seems that the "The maximum retry count" cannot be set in wsHttpBinding. I could, of course, create a customBinding for that purpose (and I tried but got another strange exception). However, I am wondering if the wsHttpBinding could possibly work.
Thanks in advance,
Phil
|
|
|
|
|
The ServiceBehavior transactiontimeout attribute was set to 00:10:00 (10 minutes) which overrided the inactivity timeout. We updated this setting and finally got success.
However, we definetely have to work on our database performance issues (probably due to some lacks in the design of deletion(cascade delete involved)). But that's another issue.
Oh welll...
Phil
|
|
|
|
|
1. How to read and write registry using configuration Management Application Block 5.0
2. How to keep my logging settings in registry and how to ovveride that logging setting in app.config/web.config.
3. How to keep my logging settings in database and how to ovveride that logging setting in app.config/web.config.
4. I am not able to find more code samples and documentation on CMAB 5.0
Please help on the above items.
Thanks in advance.
Vamshi Krishna.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
