3

    Oct 18, 2007#31

    I used UltraEdit at work a couple of years ago and loved it to bits.
    Now, I bought a new computer, and decided to try it again. To my extreme horror, the starting takes a VERY long time.

    It takes about 3 seconds to show the UEdit window.
    Then it takes about another 3 seconds to show the file.

    How do you expect me to buy a license with this kind of performance? What has happened to UEdit?

    Since this new version is rubbish and I was satisfied with the version from a couple of years ago, is it possible to buy an old version?

    Please inform,
    Sander

    6,686585
    Grand MasterGrand Master
    6,686585

      Oct 18, 2007#32

      This is a user-to-user forum. None of us can answer your question. You could have saved a lot of time reading the paragraph at top of the forum pages and contacted IDM support per email instead of creating an account for the user forums and writing this here.

      Just one answer to one of your questions:

      What has happened to UEdit?

      LOTS of features has been added which makes the EXE much bigger and many other additional files must be loaded on startup, some are loaded later on first use.

      You can also ask Microsoft or Adobe why the starting time of their applications has increased. My Pentium 166 MHz with Win95 boots within 15 seconds from pressing the power button till everthing is loaded and I can work (8 seconds needs the BIOS). My Pentium 4 with 2 GHz with WinXP SP2 needs for the same boot procedure 35 seconds although this computer is MUCH faster (5 seconds needs the BIOS). And most other need even much more time to boot their Windows XP.

      If you want a simple text editor with no extras making your work faster, buy a simple text editor. I'm sure, IDM will offer you an older version. But is the starting time of 1 or 3 seconds important when you now with the new version can do some things in 10 seconds where you need 3 hours with the older version because the older version does not have the feature needed for making work more efficient?

      I use for myself still Acrobat Reader 5 (with most of the plugins moved to a different folder) and not latest version because there is no benefit for me using the latest version. I don't need any feature introduced by Adobe since v6.0 to view PDF files. So I decided to use the Reader version which shows me a PDF file in 1-2 seconds even on my ancient computers.
      Best regards from an UC/UE/UES for Windows user from Austria

      3

        Oct 18, 2007#33

        Hi Mofi,

        Thank you for your answer.

        Ok, I can't stand to wait 6 seconds for every single document I open. This, since I use the editor to open hex, txt, programming files etc, so I'm doing this 50+ times per (work-)day.

        Could you please tell me the last version which was fast, so I know which version to ask for?

        30
        Basic UserBasic User
        30

          Oct 18, 2007#34

          Hi,

          Did you use the UE13.20+1-Version?
          What happens, when you kill all non-microsoft-executibles in taskmanager and then start UE again?

          If it still starts slower, you can try Process-Monitor "procmon.exe" from SysInternals to see, which disk-/registry access takes so much time.

          Greetings,
          mik0001

          6,686585
          Grand MasterGrand Master
          6,686585

            Oct 19, 2007#35

            6 seconds should be needed only on first start after Windows start. Every further start should be done much faster because of the Windows file caching system. If it needs always 6 seconds another process or a setting is causing the long start time. Use Process Monitor to detect what is causing the long start time.

            Alternatively you could do the what Microsoft does for Office and IE and Adobe does for the Adobe Reader - load UltraEdit on start of Windows and let it run more or less visible in the background all the time for fast editing of files.

            To do this, open Advanced - Configuration and set following settings:

            Editor - New File Creation - Create new EDIT file when opening with no other files = unchecked
            File Handling - Load - Reload files previously open on startup = unchecked
            Application Layout - Miscellaneous - Allow multiple instances = unchecked
            Application Layout - Miscellaneous - Minimize on last file close = checked
            Application Layout - Miscellaneous - Minimize on System Tray = checked

            Then create (or copy an existing) shortcut to to uedit32.exe (i.e. UltraEdit.lnk) in the Startup folder in the Windows start menu. All shortcuts there are executed on Windows start automatically and therefore start the application specified in the shortcut. (You can avoid this when holding the SHIFT key pressed during Windows start.)
            After creating or copying this shortcut to uedit32.exe, right click on it and choose Properties from the context menu. For Run select Minimize and press OK.

            So now UltraEdit is started on Windows start, minimized to system tray.

            Whenever you open now a text file with double click, UltraEdit is already running and so only the file must be loaded and the UltraEdit window must be brought to foreground which is extremely fast done.

            You only have to take attention not closing UltraEdit when editing of a file is finished. Close only the file using for example Ctrl+F4. With this method you can edit 50 files per day without starting and closing UltraEdit also 50 times per day.

            Which version is fast? Well, that depends what features you need. UltraEdit v10.10c is a very fast starting version with appropriate settings. But UE v11.20b also starts initially very fast with appropriate settings. On my computer every version starts within 1 second except the first start after Windows start when the files of UltraEdit are not present in file cache (RAM).

            Well, I have extremely optimized computers. For example all the configuration files of UltraEdit are in the program directory and with some simple tricks I made sure that all UltraEdit files are stored on the hard disk surface in the same area which avoids the necessity to move the read/write head of the hard disk several times to completely different positions for loading all the files loaded on UltraEdit start.
            Best regards from an UC/UE/UES for Windows user from Austria

            3

              Oct 19, 2007#36

              Ok, the CTRL-F4 workaround helps a lot.

              I just hope IDM would fix this bug (judging by the amount of others who have the same problem, I'd think it would be a priority).

              Thanks for the info, I'll test the latest version now.

              4
              NewbieNewbie
              4

                Oct 19, 2007#37

                @mofi
                "Well, I have extremely optimized computers. For example all the configuration files of UltraEdit are in the program directory and with some simple tricks I made sure that all UltraEdit files are stored on the hard disk surface in the same area which avoids the necessity to move the read/write head of the hard disk several times to completely different positions for loading all the files loaded on UltraEdit start. "
                _________________

                Would you care to share those simple tricks??

                Ruben

                6,686585
                Grand MasterGrand Master
                6,686585

                  Oct 19, 2007#38

                  Users with Windows XP or higher has it very easy. The Windows Prefetcher does most of the job. If you want to know what the prefetcher is, see Wikipedia Prefetcher and on MSDN the article Windows XP: Kernel Improvements Create a More Robust, Powerful, and Scalable OS written by Mark Russinovich (Sysinternals, you know) and David Solomon.

                  What I additionally do on my Windows XP computer is following:

                  After installing the monthly Windows security updates (released on every second Tuesday of the month) and rebooting Windows I delete all the temporary files in the temp folder(s) and some other temporary files, caches and not needed uninstall information of the security updates. Important here is to delete all files in the Windows\Prefetch directory permanently (not to trash). You can trust me this is safe.

                  The prefetcher makes now the next 2 weeks its work and collects the data how to organize the files best to start it fast. 2 weeks after deleting all prefetch files including Layout.ini I delete again all the files in the temp folder(s) (only 1 on my computer because I have deleted the users TEMP environment variable). Then I run manually the defragmentation tool of Windows XP. That's it.


                  For my other computers with Windows 98 and Windows 95 and also for Windows XP, I do following after installation of a new version:

                  Move the whole program directory of the just installed program to a different drive. Then I defrag the programs drive after deleting all the temp files. Then I copy back the program directory, defrag the programs drive again and last I delete the copy of the program directory on the other drive. If you have Win98 and you watch the details during defragmentation you will see that the files of the program are now in the same area. If you want that perfect, you could log with Filemon in which order which files are loaded and copy that files in this order from the other drive back to the programs drive. But I don't do that.

                  Above is just a little hint to get programs faster. It needs much more to get whole system permanently fast. But its useless to tell you in detail how because it is required to apply the "keep your computer fast and clean method" from the beginning on. Before you install Windows you have to divide your hard disk into at least 4 partitions:
                  • a system partition with the OS and the smaller programs regularly updated
                  • a program partition where big program suites like MS Office are installed
                  • a small data partition where your data files are stored
                  • a partition for temporary files
                  Usage of more than 1 hard disk would be even better, but I don't need so much space for my work.

                  After installing Windows many registry hacks and modifications must be done to make sure that all temporary files including the files Internet Explorer, other browsers and programs create temporarily are created on the TEMP partition. Program suites must be installed with custom setup to the program partition, small programs are installed with custom setup either to the system or the program partition. All programs must be setup to use directories on the data partition for files I create or edit. (There was never a file in "My Documents" on my Windows XP except the pre-installed ones.) And much, much more. With such an effort before and after every program install you can keep the 2 program drives fast. Most computer users need only a few minutes or even seconds to install a program. I need always at least 30 minutes, on first install much more to install and configure it perfectly for my needs. But I got this time back within next 3-7 days because of more efficient work. Nobody in my department is as fast as I when manipulating data. The configuration and deep knowledge of the tools I use makes the difference.

                  The data partition is regularly (every two to three months) completely copied to the temp partition, quick formatted and then all is copied back (after using UltraSentry to destroy all data bytes on the empty data drive after the quick format). Data not needed anymore daily are packed with RAR (decrease number of files and space). The partition with the temporary files is once per month simply quickly formatted which require a booting from another device because of the index.dat files on this drive. That's why my temp drives are FAT32 partitions which I can quickly format with a Win98 floppy boot disk. (UltraSentry is again used to really clean this drive after formatting).

                  My Windows XP is six years old and as fast as on first day. All my colleagues complain periodically that their computers are getting slower and slower and slower and they want a new computer (and some have got it), a larger hard disk (and most of them bought it from their own pockets), more RAM (some got it), etc. But my unmodified computer is still faster than there upgraded computers, although I was forced twice to get my computer into a completely new network environment with additional program changes (Outlook, ...). As long as they don't change how they manage their programs and files, a new hardware will solve their speed problems only for the next six to twelve months. That's what I think.
                  Best regards from an UC/UE/UES for Windows user from Austria

                  4
                  NewbieNewbie
                  4

                    Oct 20, 2007#39

                    whow, thanks a lot, Some of that stuff I am doing too, but the thing about prefetch sounds quite interesting

                    Again, thanks for sharing

                    Ruben

                    40
                    Basic UserBasic User
                    40

                      Oct 22, 2007#40

                      although I also partition my drives, doing this decreases performance.
                      If you divide a HDD into 2 equal partitions, file reads/writes for the outermost track of the inner partition will be 1.4 times slower compared to outer partition. If you divide a HDD into 4 equal partitions, access to last one will be twice slower than the access to first one
                      (hope I'm not wrong with maths). :)

                      Temp files are often accessed so they should be on the first, fastest partition.
                      In fact from the point of view of perfomance it's best to have a single partition, but that's inconvenient for backups. So I have one for OS+Apps+temp files, and one for data. Sometimes one more for OS partition images and other backups.
                      I also use a defrag program that puts the most often accessed files on the outer tracks of the partition.

                      6,686585
                      Grand MasterGrand Master
                      6,686585

                        Oct 22, 2007#41

                        You are right with the head movements caused by the partitions. But my experience is that temporary files on a separate partition is always better than on the system partition. Why?

                        When a program is launched normally first all program files are loaded to memory and no temp files are created until first file is loaded. So there is only 1 head move from inner to outer area of the disk after starting the application. Further the file caching mechanism of Windows avoids too often reads/write from temp files directly from/to hard disk. The performance gain by having the temporary files on another partition and so avoiding fragmentation of the system drive is higher than the loss of speed by working on the outer area.

                        But I agree with the real temporary files. They should be on the inner partition. And this is true on my computers too. %temp% == %windir%\temp\
                        That's why I always delete the temporary files and defragment the system drive before installing a new version/program. I have only all other "temporary" - no, better "fixed saved files for temporary usage only" - files on the temp partition.

                        So the real temp files automatically created and deleted are still on the system drive (after the system and program files on the hard disk). But the cookies, browser cache files, browser history cache, files downloaded from the web, email attachments saved to hard disk, the default email storage files (not the real email archives), the files extracted from an archive, files created for testing purposes, network files copied temporary to local disk for editing before copying back to the network, graphic files from cameras or from screenshots, etc. are stored by default on my temp partition. Those files for temporary usage are not automatically created and deleted by programs. Their life time is greater than the program running time. But their life time is often shorter than 2 weeks. Most of them are deleted on the same day.

                        Sorry for making not clear what I understand as temporary file. The real temp files are in my point of view just memory data stored for security to hard disk for a short time. The few programs I have written for PC avoid creation of such temporary files when I know the data size is limited. Those programs handle whole data in memory.

                        I played with the idea to create permanently a ram disk and set %temp% to this disk. But sometimes it was helpful that %temp% was on the hard disk when a program crashed. That makes it possible to get data back. So I don't use a ram disk.
                        Best regards from an UC/UE/UES for Windows user from Austria

                        1
                        NewbieNewbie
                        1

                          Oct 31, 2007#42

                          Wow, having now read all of the content herein under the search term "startup slow", I am impressed by how complex the issue appears. The users of this board are certainly knowledgeable and committed!! Thanks for the great info!

                          The most commonly suggested corrective action seems to be stripping all FTP related entries from the ini file. That seems to have worked for several people.

                          Looking into my uedit32.ini file for FTP related entries, I see LOTS of stuff, and am not sure what is FTP related. If this is truly the right way to speed the startup of UE, I respectfully suggest that IDM might provide a small utility program that strips out the offending material in a controlled way, so that users like me don't accidentally mangle thier own ini files. Just an an uninformed idea.

                          I'm a bit confused as to why this should matter, though, as the FTP sites are not being opened. I wonder if slow startup an unavoidable consequence of storing past FTP site info.

                          I tried to use ProcMon to analyze the startup process, but most of that is over my head. It seems to spend most of it's time in a thread called "Wait:Executive" I dunno if that imparts anything useful.

                          Anyway, in the short term, it seems most effective for me to simply return to ver 13.00, which loaded much quicker, and check back from time to time to look for developments.

                          Even if that was the last version I could ever use, it would still be my editor of choice. UE works great.

                          12
                          Basic UserBasic User
                          12

                            Feb 14, 2008#43

                            Is ANYONE else out there still seeing slow UE load times as of 13.20a?

                            Are there any specific UE configuration changes that anyone knows aggravate the issue? It seems like after adding some of the DOS batch file syntax highlighting stuff to my default wordfile, UE started taking a LOT longer compared to before the change... it was very noticeable, but then taking the DOS syntax stuff OUT of the the file did not 'reverse' the issue all of the way though it seemed a bit better...

                            This is all really weird that this issue appears to be so tough to nail down for IDM... theres alot of really good and valid "generic" system tuning advice in here from guys like mofi, but none of these things are the "real" issue... it's definitely a "UE" code thing.

                            Has anyone heard any ideas from IDM about whether or not they might add a loader process that would keep most of the program in memory (with most or all of whatever 'overhead' work it needs to do already having been done) without having to have the UE UI open all the time? I know there's a share of ppl out there who might even b!t@h about that, but there's a reason software devs use this method when over time their app has gotten bigger and bigger with features to the point it impacts load time and user experience... the CTRL+F4 thing is indeed an ok workaround, and combined with minimize to system tray option, gets the UI out of your way when you're done editing docs for the moment, but still... 'ah... 'nuff said.

                            6,686585
                            Grand MasterGrand Master
                            6,686585

                              Feb 15, 2008#44

                              What means "long" in your point of view. Could you be more precise. And there should be a big difference (less than 1 second instead of several seconds) between first start of UltraEdit after starting the computer and restarts later. As often written check with Filemon, Regmon or better Process Monitor of Windows Sysinternals what causes long delays during a program start.

                              12
                              Basic UserBasic User
                              12

                                Feb 15, 2008#45

                                Actually, after checking again... I realized that I was seeing this behavior on a 13.10 installation. I am in the process of 'moving' to a new laptop and migrating all my data. Anyhow, on the new system I'm running 13.20a and things do seem to be better... so it looks I jumped the gun with my post here, sorry. Could have SWORN I'd upgraded the old system to 13.20 :-(.

                                That said, as for the specifics... the time lag was on the order being discussed here in the thread already... anywhere from 5 to 7 seconds. And while I've certainly seen the advice to try using filemon, procmon, etc etc to trace things (which I've often done in other situations), respectfully... doing so just doesn't seem to apply very often in scenarios where an application specific change causes the 'problem'.

                                Read more posts (7 remaining)