1

Closed

Editor takes a long time to load under .NET 4.0

description

It takes a long time (Sometimes nearly 20 seconds) for the Task Editor to launch.
All the code is being done on the GUI thread, so a wait cursor (Or marquee bar) are not possible to be used in the "Owner application". Please can you find a way to display the outline of the editor with a waitcursor and then perform the population of tabs etc after the form has "Shown".

file attachments

Closed Mar 20, 2012 at 9:10 PM by dahall
To eliminate load delays, regardless of the .NET version, make sure the target platform for the calling assembly/application is set to x86.

comments

smurfiv wrote Jan 26, 2012 at 6:48 PM

BTW: These timings are from using 1.7.2 "Pre-release" (Same in 1.7.1) on Win 7 x64

smurfiv wrote Jan 30, 2012 at 6:55 PM

I'll try and keep the timing discussions in here..
When using the taskeditor "ShowDialog" it takes along while for the editor to show (A video is present in the other issue)

One of the things that this could be down to, is that the parent application that I am using is a .Net 4. The Task Editor is .Net 3.5 and needs to load in projects that are marked as .Net 2
It could be that this display delay is down to the Mix of .Net frameworks. i.e. it has to load another .Net framework into the running workspace environment to display the editor.

wrote Jan 30, 2012 at 7:36 PM

dahall wrote Jan 30, 2012 at 7:36 PM

I don't think the different versions is the reason. The TestTaskService project included in the source code is running against .NET Framework 3.5 and loads the TaskScheduler assembly (marked .NET 2) without any problem or slow down. I have attached a zip file with that program and all supporting assemblies. Please extract and run on the problem system and let me know if you experience delays in opening TaskEditDialog.

smurfiv wrote Jan 31, 2012 at 4:26 PM

Thanks
I start it up, Wait about 2 seconds to load
Click on Editor test, then click run. It then takes about 5 seconds to load the editor. Clicking ok, brings the windows back almost instantly.
Looked in Process explorer and it shows that thi si running completely within the .Net 2 space

BTW >net 3.5 runs .Net 2 applications as it is backward compatible (i.e. like in Win2k8) you only need to install .Net 3.5 SP1 and it will run every .Net app up to 3.5.
Note: Where as .Net 4 is the 1st to disable backward compatibility, but there is a workaround If [and Only If] IFF .Net 3.5 is not installed and the app is "well behaved"; But it requires special config file settings.

So the next thing will be to have this Test app compiled in .Net 4 with the target framework set to .Net 4 runtime and then for that to be used for a timing test.

wrote Jan 31, 2012 at 6:00 PM

smurfiv wrote Jan 31, 2012 at 6:00 PM

I took the latest test app from this code base.
Removed all the other things that were not the based on the test app code
opened the vcproj in VS 2010 and set the properties to be a .Net 4 Profile
Copied in the dll's from the Test app that you included here. and set them as references in the project.
Built a debug version (Not much difference in .Net whichever it is)
ran the Debug version from outside of the dev environment
Clicked on the Edit button, then the Test.
Bang.. An exception occurred.
Picture added [Test Crash in .Net 4]

smurfiv wrote Jan 31, 2012 at 6:37 PM

Oops.. The crash was the fault of the test app, not the Dll's it is testing..
If you look at the exception in the picture it shows your username, So I replaced the user string with the following line:
     string user = System.Security.Principal.WindowsIdentity.GetCurrent().Name;
and re-ran.. No crash.
BUT
  • It was back to the 18 seconds plus for the initial load time.
  • Performing from the registration or from the GetTask does not effect the time.
  • Pressing OK, brings the editor back almost immediately.

dahall wrote Feb 28, 2012 at 9:04 PM

I have verified that this is the result of the assemblies being compiled for .NET pre-4.0 and this is a common/known problems for all .NET assemblies. For the next release, I will release two versions of the download: on for .NET 2.0/3.5 and another for 4.0.

wrote Feb 28, 2012 at 9:05 PM

wrote Feb 28, 2012 at 9:06 PM

smurfiv wrote Mar 16, 2012 at 4:54 PM

Is this in 1.8.1 ?

wrote Mar 16, 2012 at 5:29 PM

dahall wrote Mar 16, 2012 at 5:29 PM

Attached are the assemblies for 1.8.1 compiled against .NET 4. Will you test and let me know if you see the same delay as before?

smurfiv wrote Mar 20, 2012 at 6:28 PM

Nearly there.
First edit load takes 12 seconds, subsequent loads take 7 (No initial creation).
You will also need to supply the other Dll's as .Net 2 otherwise, the whole thing is negated (i.e. Areo, TimeSpan2, etc)
Or are these controls not needed ?

dahall wrote Mar 20, 2012 at 9:07 PM

I found the real problem. The .NET version has nothing to do with this. The project assemblies are compiled with "Any CPU" as the target platform, a carryover from the original development done under VS2008. What this translates to is that the 32-bit JIT compiler is being used. If your application is using "Any CPU" or x64 as the target, you will see a load delay due to WOW3264 being invoked to run the 32-bit JIT code from a 64-bit application. If you have the choice, use the default VS2010 setting of x86 as the target platform for your application assembly. With this new discovery, I will not be releasing the library compiled against .NET 4.0 as it makes no difference. In my test app, when target platform is x86, the dialog loads in about 1.5 seconds. If target platform is "Any CPU" or x64, it takes over 10 seconds to load.

wrote Mar 20, 2012 at 9:08 PM

wrote Mar 20, 2012 at 9:08 PM

wrote Mar 20, 2012 at 9:09 PM

wrote Mar 20, 2012 at 9:10 PM

wrote Feb 22, 2013 at 12:21 AM

wrote May 16, 2013 at 11:49 AM