Startup Speed

[Inray]

IT'S 4-5 SECONDS.. You people can't wait FOUR FREAKING SECONDS!!!! Take a deep breadth...it'll calm you down

It's not that simple, hbae. For most of us, UE is not just another utility in our collection, but a professional tool. Besides spending hours per day using it, I use explorer's "open with UE" menu to view tens of files per day. I cannot stand that lag when MultiEdit or other huge pro-class editors I used, open instantly.
For example VisualStudio .NET IDE in my primary dev machine, loads faster even instantly when runs from cache.

It's just my opinion though

[Mofi]

I use still V10.10c, the latest version without Armadillo. UltraEdit starts in one second on all my machines (Win95 Pentium 166 MHz, Win98 Celeron 500 MHz, WinXP Pentium4 2 GHz).

I also tried the latest 10.20 version and it starts as fast as the v10.10c.

But there are two reasons, why UltraEdit starts so fast.

First, I have set UltraEdit to store everything in the INI file and nothing in the registry. I use still the old V8.xx toolbar and menus, which are stored in the INI file (ini settings also manually sorted alphabetically). Loading settings from a 18 kB INI file is simply much faster than loading it from a 600 kB (Win95), 4.5 MB (Win98) or 16 MB (WinXP) registry, which is not sorted, often fragmented and contains still deleted data, even if you can't see the deleted data with regedit any more.

Second, my computers are extremly optimized for speed.

I killed every unneeded autostart program with Autoruns.
You can find the informations about your autostart programs in the internet. Delete autostart entries only, if you are sure, it is save. WinXP users can create a restore point before playing with the autostart entries.

I remove the "deleted" WinXP registry entries with NTRegOpt. On Win9x start in MS-DOS-Mode and run this batch file (REGOPT.BAT) for recreating an optimized registry.

----- REGOPT.BAT -----
@echo off
C:
cd %windir%
smartdrv 16384
echo Extracting registry data ...
regedit /e FULL.REG
echo Make registry backup ...
attrib -r -h -s SYSTEM.DA?
attrib -r -h -s USER.DA?
if exist SYSTEM.DA0 del SYSTEM.DA0 >nul
if exist USER.DA0 del USER.DA0 >nul
ren SYSTEM.DAT SYSTEM.DAO
ren USER.DAT USER.DAO
echo Recreate registry ...
regedit /c FULL.REG
del FULL.REG >nul
echo Registry optimization finished - reboot !!!
pause
exit
----- REGOPT.BAT -----
Change the drive letter in line 2, if Win9x is not installed on drive C.

Clean up your hard disk with windows Disk Cleanup (cleanmgr.exe) in the start menu - Programs - Accessories - System Tools. On WinXP click on More Options and Clean Up System Restore before executing the Disk Cleanup to delete old system restore point data. Manually delete everything in the %windir%\Temp directory and on WinXP in the %windir%\prefetch directory. Other temporary files are harder to clean up and needs expert knowledge.

Defragment the drives with windows defragmentation tool.

On WinNT/Win2K use PageDefrag to defrag the registry, pagefile.sys and other permanently used system files.

You can find many other useful optimization tips in the internet. If your PC needs more than 45 seconds to start (measured from pressing the power button till windows fully has finished), your machine can still be optimized.

And don't forget to optimize your virus scanner. The are several options, which are save to be changed and increases performance a lot.

[Inray]

I use still V10.10c, the latest version without Armadillo. UltraEdit starts in one second on all my machines

Same here when use pre-Armadillo UE builds

I also tried the latest 10.20 version and it starts as fast as the V10.10c.

No way, sorry. As already told, Armadillo startup lag is a known and confirmed (by its author) side effect of this protection.

First, I have set UltraEdit to store everything in the ini-file and nothing in the registry. I use still the old V8.xx toolbar and menus, which are stored in the ini-file (ini settings also manually sorted alphabetically). Loading settings from a 18 kB ini-file is simply much faster than loading it from a 600 kB (Win95), 4.5 MB (Win98) or 16 MB (WinXP) registry, which is not sorted, often fragmented and contains still deleted data, even if you can't see the deleted data with regedit any more.

I'm using ini file too but that's not an issue. Accessing registry for reading known keys is ultra fast, even when registry file is fragmented because reg API use direct random access and not sequencial. As you say registry defragment can help other situations (like Win boot time) but makes no difference using UltraEdit.

Second, my computers are extremly optimized for speed.
I killed every uneeded autostart program with Autoruns.
You can find the informations about your autostart programs in the internet.

No need to use a utility to cleanup unused startup processes. Just visit related registry keys (eg RUN, RUNONCE etc) and remove useless entries. BTW I always do that with all computers I have access to, especially those used for development.

I remove the "deleted" WinXP registry entries with NTRegOpt. On Win9x start in MS-DOS-Mode and run this batch file (REGOPT.BAT) for recreating an optimized registry.

I'm using my own login/logout scripts that clear all MRU, RecentFiles, Stream folders, RunMRU data as well as all temp files/folders before log in or log out.

Clean up your hard disk with windows Disk Cleanup (cleanmgr.exe) in the start menu - Programs - Accessories - System Tools.

CLEANMGR /Sagerun:xx is called from my own shutdown scripts that also erase other "protected" data files

Defragment the drives with windows defragmentation tool.

PerfectDisk 6 is installed in all of our company's machine and defrag on per/day basis.

You can find many other usefull optimization tips in the internet. If your PC needs more than 45 seconds to start

No problem Mofi, Windows startup is very fast (<20sec).

And don't forget to optimize your virus scanner.

Virus scanner on a development machine? You must be kidding I have F-Prot installed on all LAN machines, but used on-demand to prevent silly services and tasks from running.

As you understand, i have optimized my computers, actually optimization is a must for me, not only because of UE but due my work nature. You cannot code debug and run system drivers and apps in a machine with NAV or other huge garbageware installed.
Unfortunately UE is slow on startup and the reason is known. It is slow on p4/3.4Ghz / 2GB or twin CPU/4GB machines (SCSI320/SATA) and I can do nothing for that.
On same machines, tools like VS.NET, MultiEdit 9, VSlickEd fire up in a fraction of a second, and these are multiMegabyte heavy apps.

Regards

[Mofi]

I also tried the latest 10.20 version and it starts as fast as the v10.10c.

No way, sorry. As already told, Armadillo startup lag is a known and confirmed (by its author) side effect of this protection.

V10.20c starts on my WinXp definitively in about 1 second, even if the author of Armadillo writes something different. If you can't believe me, here is the start and end of a filemon log with absolut time. Maybe the prefetch mechanism of WinXP is responsible for the speed performance.

Code: Select all

124    14:50:01   uedit32.exe:404     QUERY INFORMATION   C:\Programs\UltraEd\uedit32.exe              SUCCESS   FileNameInformation
125    14:50:01   uedit32.exe:404     OPEN                C:\WINDOWS\Prefetch\UEDIT32.EXE-12B96E1D.pf  SUCCESS   Options: Open  Access: All
126    14:50:01   uedit32.exe:404     QUERY INFORMATION   C:\WINDOWS\Prefetch\UEDIT32.EXE-12B96E1D.pf  SUCCESS   Length: 34632
127    14:50:01   uedit32.exe:404     READ                C:\WINDOWS\Prefetch\UEDIT32.EXE-12B96E1D.pf  SUCCESS   Offset: 0 Length: 34632
:
:
:
3903   14:50:02   uedit32.exe:404     OPEN                C:\Programs\UltraEd\Config\UETMPLTE.DAT      SUCCESS   Options: Open  Access: All
3904   14:50:02   uedit32.exe:404     READ                C:\Programs\UltraEd\Config\UETMPLTE.DAT      SUCCESS   Offset: 0 Length: 604
3905   14:50:02   uedit32.exe:404     CLOSE               C:\Programs\UltraEd\Config\UETMPLTE.DAT      SUCCESS
3906   14:50:02   explorer.exe:1880   QUERY INFORMATION   C:\Programs\Ultraed\ueres.dll                SUCCESS   Attributes: A
3907   14:50:02   explorer.exe:1880   OPEN                C:\Programs\Ultraed\ueres.dll                SUCCESS   Options: Open  Access: Execute
3908   14:50:02   explorer.exe:1880   QUERY INFORMATION   C:\Programs\Ultraed\ueres.dll                SUCCESS   Length: 499712
3909   14:50:02   explorer.exe:1880   CLOSE               C:\Programs\Ultraed\ueres.dll                SUCCESS

I'm using ini file too but that's not an issue. Accessing registry for reading known keys is ultra fast, even when registry file is fragmented because reg API use direct random access and not sequencial. As you say registry defragment can help other situations (like Win boot time) but makes no difference using UltraEdit.

Sure, the registry is cached fully in RAM and maybe WinXP now has fast accessing mechanism, but on my slow Win9x machines the difference between working with UltraEdit with registry or only with ini-file is significant slower/faster.

The other optimizations I wrote are for general, not for helping to especially start UE faster.

No need to use a utility to cleanup unused startup processes. Just visit related registry keys (eg RUN, RUNONCE etc) and remove useless entries. BTW i always do that with all computers i have access to, especially those used for development.

Yes, I delete programs at these keys and changed services also manually in the past. But Autoruns is easier to use. Unzip the program, run it and change the settings. Autoruns needs no install and it shows the complete "path" (registry, drive), where the autostart is set and if you enable everything in the options menu, you maybe will see a lot, never seen before.

I'm using my own login/logout scripts that clear all MRU, RecentFiles, Stream folders, RunMRU data as well as all temp files/folders before log in or log out.

Perfect, but deleting MRUs in the registry do not reduce the size of the registry itself.

CLEANMGR / Sagerun: xx is called from my own shutdown scripts that also erase other "protected" data files.

The index.dat files of IE? I delete these files sometimes before WinNT starts with the standard windows setup function, but this is something for experts. These files increases permanently (if IE is used for browsing) and are always cached in RAM. Because I use Opera, it is not necessary to delete the index.dat files very often on my machines.

Virus scanner on a development machine ? You must be kidding :) I have F-Prot installed on all LAN machines, but used on-demand to prevent silly services and tasks from running.

I also have installed the virus scanner only for on-demand scans, but please don't tell this the IT experts of our company. They will kill me.

[Inray]

Hi Mofi,

V10.20c starts on my WinXp definitively in about 1 second

I've no reason not to believe you Mofi. It just sounds weird because Chad, Armadillo's author, has confirmed startup delay and every user of that protection, including myself, has noticed that. Actually it's one reason my company dropped Armadillo from our small and fast projects.

The index.dat files of IE?

As already told you, i'm using shutdown scripts (WinXP), so every deletion or other cleanup command goes there. Index.dat for example are unlocked when shutdown scripts run, so it's easy to remove using a single command.

I also have installed the virus scanner only for on-demand scans, but please don't tell this the IT experts of our company. They will kill me.

Hehe that was the best I've heared today

Best regards

[Craig]

I'm squarely in the "UE loads too slowly" camp.

Software, particulary a lightweight program like UE, should not be getting slower with newer versions. When MS Word 2003 loads more quickly than UE, obviously there is a problem.

If only PrimalScript weren't so pricey....

[bhoylma]

I start and leave an instance of UE running and minimized to the system tray. I also have the 'Allow multiple instances' OFF and 'Minimize on last close' set to ON. With these options I incur the startup overhead of UE only once (you could even put it in your Startup folder). Then each subsequent edit only has to load the file and apply any context-related view information to the file content and it's up in a flash.

As I've been doing it this way for as long as I've used UE (version 5 I believe) I've never really noticed any startup issues along the way.

YMMV.

Peace.

[Inray]

Starting and leaving active an instance of UE, is just a workaround. I do that too, to avoid startup delay, but IMHO Ian has to do something giving back to UE its lost speed AND stability.

As for PrimalScript, i can only think of it as a script language IDE not a generic programmer's editor.

Regards

[epaalx]

I believe it was 10.10c, the last version with out Armadillo protection.

That's the reason why I have not upgraded to 10.20c.

Besides, UE v10 has so many other functional deficiencies, I think IDM should be concentrating on fixing up the functional holes (see my various posts) before being sure that he's got a captured audience. Everytime I find a new functional hole, I starting thinking about getting a new editor.

(It still gets me that after 10 years, UE can't handle syntax highlighting and word-wrapping at same time.)

[Inray]

UE v10 has so many other functional deficiencies, I think IDM should be concentrating on fixing up the functional holes (see my various posts) before being sure that he's got a captured audience. Everytime I find a new functional hole, I starting thinking about getting a new editor.

(It still gets me that after 10 years, UE can't handle syntax highlighting and word-wrapping at same time.)

Absolutely agreed.
Ian and UE development team, must fix all known deficiencies and bugs before getting involved with new projects like UC or even a new UE version.

Regards

[Redmumba]

I've actually been having this problem for a long time as well (or at least, it seems like a long time, maybe a year or two), and have experienced the same thing. However, since this is the first time I've sought to find a solution, I only now have fixed it. Like somebody mentioned, changing "Use Registry" has completely fixed the problem! It took me 13 seconds to startup before (I timed it), now its just like notepad. Just starts instantly... try using 10..20c with Registry enabled.... maybe it'll work? If I'm just being stupidly redundant, then just ignore me. >.<

[kahlan]

I've actually been having this problem for a long time as well (or at least, it seems like a long time, maybe a year or two), and have experienced the same thing. However, since this is the first time I've sought to find a solution, I only now have fixed it. Like somebody mentioned, changing "Use Registry" has completely fixed the problem! It took me 13 seconds to startup before (I timed it), now its just like notepad. Just starts instantly... try using 10..20c with Registry enabled.... maybe it'll work? If I'm just being stupidly redundant, then just ignore me. >.<

This is "known". Before Ultraedit can open the ini file, your virusscanner first locks the file and examines it for virusses. I believe UltraEdit tries to load the ini file several times, probably for each setting.
The registry does not have this behaviour.

[idm]

Hi Folks,

This is Ian responding. I personally review the forums and respond to some of the issues specifically. Our support team responds to hundreds of emails a day and it's best to email us with support and performance issues to support@idmcomp.com for assistance.

Having seen this thread I wanted to take the opportunity to make a few comments.

1) Startup time - UltraEdit has got slower over the last few main releases (as do most products unfortunately) for several reasons. All of these accumulate. Most of the reasons have been highlighted in the earlier discussion and so I will not repeat these. I would comment that generally on our systems even a 400 MHZ system UE's startup time is around 3-4 seconds on the 400 MHZ system and 1-2 seconds on a fast system.

There were things with the copy protection that made UltraEdit slower in the past and we addressed these.

Before anyone responds, I know that others have seen longer times. There can be a lot of reasons for this and if you email support@idmcomp.com we will be glad to discuss each case individually.

However, the main point to my writing is this - we listen! The next release addresses the issue with Armadillo, it will no longer be used. Additionally, we have changed the menu/toolbar framework and this will provide much better functionality and performance.

The result of this is a material increase in performance with the soon to be released v11.00 (Q1 '05). We are leaving our present copy protection scheme with the release of v11.00 and will be implementing a scheme that will not interfere with the programs performance.

This is more than a one-time-fix; it's an affirmation from IDM to you, our paying customer, that we will not trade protection for performance in the name of keeping others who steal our software at bay.

We do get a lot of users that steal our software, however our paying customers are more important. For those who do choose to steal our products I can only say that you are doing yourself more of an injustice than IDM. If you are using IDM software illegally, you are cheating yourself out of the support and company backbone registered users enjoy. You are also embarrassing yourself over $35 and risking your own reputation and family well being for fraud. Integrity means many things to many people, but as it was best put by one of our own users, Integrity is something that God gives you and that something only you can give away. The choice is yours.

I want to respond to the side comment that also crept in regarding "syntax highlighting and word-wrapping ". I appreciate the feedback - an email would have been better. We have taken on additional engineering staff to help with enhancements and features and this will be evident with our next release. We will do all we reasonably can to address this issue in the next release, and if not in the v11.10 that will of course follow. This issue had not be brought to our attention for some time and had slipped in priority.

I do want to say to all who have been loyal and true to IDM for the past decade, "thank you" and we do listen!

Thanks and God bless,

Ian.

[Inray]

Glad to hear these news, especially Armadillo dropping. I hope v11 will be the best UE ever made.

Thanks Ian

[irkregent]

Thanks for the update, Ian. Too bad there are a lot of software companies that lack your dedication to paying customers.

We're looking forward to v11!