UltraEdit Fast Startup

UltraEdit · Apr 05, 2007#12007-04-05T02:41+00:00

Folks,

I know there have been several reports of slower than expected startups of UltraEdit. As always, we have been looking into this issue as some users have sent us information to [email protected].

We have just released a hotfix that we believe will make a significant improvment to users that were seeing a slow startup. Many users, ourselves included were not experienceing this. If you are not experiencing this then you may not want to try the hotfix.

While running UltraEdit, go to the Help menu and "Check for Updates" and you will see the hotfix available.

Please remember, this is a hotfix at this time and it comes with assoicated risks. We should be releasing the changes in an "a" release in the near future.

We welcome any feedback or issues. If so, please send to [email protected].

Thanks as always,

Ian

Tripecac · Apr 05, 2007#22007-04-05T07:34+00:00

This hotfix helps a little.

Starting UE for the first time is still a little sluggish: 4-5 seconds.
Subsequent restarts are definitely the fastest yet (for version 13.x): about 2-3 seconds.

Out of curiosity, what did you change to make it start faster?

Which of the "slowness" observations on here (if any) helped you identify the bottleneck(s)?

Is our feedback on here helpful?

Is there anything we can do to help isolate the factors that have been causing slowdowns? For many of us, the slow starts are almost a show-stopper [in terms of our continued use of UE], so helping you out is definitely in our best interest!

Bego · Apr 05, 2007#32007-04-05T10:15+00:00

I think 13+5 is MUCH faster than +4.
Startup about 3 secs for the 1st time, 1 sec for following starts on my Athlon 3000 1GB RAM.
For ME this is good, but I do not say it might be even better

I also am curious as Tripecac to have a bit information what exactly was helpful and what (in rough words) was the reason for the slowness.

rds Bego

oracledba · Apr 05, 2007#42007-04-05T22:40+00:00

Just installed version 13 hotfix#6 (never tried #5).
At this point I consider the slow startup issue solved!

UE on this laptop now takes just over 1 second which I deem acceptable.
(prior to hotfix(es) we were in the 5 second range).

THANKS ULTRAEDIT.

Mofi · Apr 06, 2007#52007-04-06T12:44+00:00

If you are interested in how one of the startup speed improvements has been done, here is the answer which I detected by myself because I have had the same idea a few days before, but failed to do it with UE v13.00+4.

Uedit32.exe is now much smaller in file size as before and so it is much faster loaded from hard disk to RAM. This is done by packing the EXE with UPX like it is also done for example for Total Commander and the WinRar sfx modules up to v3.42.

Other applications like IrfanView and Opera use ASPACK.

So packing an EXE or statically loaded DLL is well known as method to decrease startup time especially on older computers with slower hard disks and bus speeds. See for example Information on Opera's Packed Executable Files for details what are the disadvantages.

Please note:
Previous versions of UE/UES cannot be packed with UPX. I have made some quick UPX packing attempts, but have had only success for some of the DLLs loaded by UE/UES. It looks like IDM has modified some code of UE to make it compatible for UPX packing (or the IDM developers find the correct packing options).

By the way: A few hours after hotfix 6 a new hotfix 7 was published by IDM.

PS: I can unpack UPX and ASPACK packed EXEs and DLLs with the great FileInfo lister plugin for Total Commander and the additional DLLs needed for this job.

Why the sfx modules are not packed anymore with UPX by default since v3.50 of WinRar and why I ignore that and still pack always the latest WinRar sfx modules with UPX can be read in history of WinRar v3.50 at point 7 in file WhatsNew.txt if you own Winrar or for example here online.

UltraEdit · Apr 06, 2007#62007-04-06T19:19+00:00

Mofi,

It is is correct that we used UPX to give us a slight improvement but this was the least of the changes that we made and gave the least benefit. This was just a part of a lot of work that was done to analyze the startup and improve it.

Thanks, Ian

Mofi · Apr 06, 2007#72007-04-06T19:49+00:00

Ian wrote:It is is correct that we used UPX to give us a slight improvement but this was the least of the changes that we made and gave the least benefit. This was just a part of a lot of work that was done to analyze the startup and improve it.

Yes, I already thought that because the startup speed improvement was too big for being made only by packing uedit32.exe and so loading the EXE faster into RAM. And in the mean time I also have seen that the unpacked EXE of UE v13.00+7 is only a little bit slower than the packed version.

Thanks Ian that you confirmed my thoughts.

hveld · Apr 09, 2007#82007-04-09T23:04+00:00

good work!
Just applied +7 patch and I see the difference, UE starts for ~1 sec. now.

Inray · Apr 10, 2007#92007-04-10T16:12+00:00

Hmm, UPX compression offers nothing in terms of UE startup lag.
Actually, upx increases app load time due to decompression overhead.

patrickdrd · Apr 11, 2007#102007-04-11T04:34+00:00

UltraEdit-32 13.00+8 (v13.00 hotfix only):

Selecting Set Font from the View menu does not display font dialog
Hang/Crash when using versioned backups
Double quotes stripped from command line of user configured tools
Data corruption when using Convert CR/LFs to Wrap with UTF-8 files

hveld · Apr 11, 2007#112007-04-11T14:32+00:00

Inray wrote:Hmm, UPX compression offers nothing in terms of UE startup lag.
Actually, upx increases app load time due to decompression overhead.

A UPX-ed file should load faster, but then it needs some time for decompression. Looks like these two compensate each other, so it doesn't matter if the file is compressed. But as they said this was the least important change, there were probably a lot more changes because +7/+8 start noticeably faster than +1.

mik0001 · Apr 12, 2007#122007-04-12T21:54+00:00

hveld wrote:A UPX-ed file should load faster, but then it needs some time for decompression. Looks like these two compensate each other, so it doesn't matter if the file is compressed. But as they said this was the least important change, there were probably a lot more changes because +7/+8 start noticeably faster than +1.

On
"http://upx.sourceforge.net/"
you can read about some advantages of UPX:
[...]
- very fast decompression: ~10 MB/sec on an ancient Pentium 133, ~200 MB/sec on an Athlon XP 2000+.
- no memory overhead for your compressed executables because of in-place decompression.
[...]
So, 200MB/sec is very fast, I think;no-one should use an Pentium 133 today

But IDM did not use the best compression yet.
It takes more time to compress, but the filesize is smaller than in the current version v13.00a. I achieved a filesize of 1,6MB (!) after recompressing it with UPX/UPX-Shell using the best compression-level.
(Small filesize means also less data to download, so why not using the best compression?).

patrickdrd · Apr 12, 2007#132007-04-12T22:01+00:00

very good point!

could you post your exe here (or a link) for us to download and use?

mik0001 · Apr 12, 2007#142007-04-12T23:02+00:00

I uploaded the best compressed uedit32.exe here (v13.00a):
[Link now removed-ask me, if you want]

have fun

patrickdrd · Apr 12, 2007#152007-04-12T23:29+00:00

Obviously you used the command:

Code: Select all

upx --brute ..\uedit32.exe

Trying that myself now, thanks for reference.