version 1.3.6 lanuchs so slower than 1.3.5

[CuriousFu]

version 1.3.6 lanuchs so slower than 1.3.5

[daxgames]

It is slower but it is doing more. It takes about 2 secs longer for 1.3.6 to launch.

Added echo. | time to top and bottom of init.bat in both v1.3.5 and v1.3.6.

v1.3.5

The current time is: 17:12:10.26
Enter the new time:
The current time is: 17:12:10.72
Enter the new time:

v1.3.6

The current time is: 17:37:09.96
Enter the new time:
The current time is: 17:37:12.34
Enter the new time:

Can you elaborate?

[gunr2171]

In 1.3.6 I'm getting around 10 second wait time between the screen showing up and the terminal being ready for input:

The current time is: 16:25:09.05
Enter the new time:
The current time is: 16:25:18.21
Enter the new time:

I'll update this post when I get 1.3.5 back on this system to see the difference.

[gunr2171]

I did a bit more scientific research into the startup performance across the 1.3.x versions of Cmder.

Observation: Version 1.3.6 takes a very long time to startup. On my work computer it's ~10 seconds.
Hypothesis: Version 1.3.6 should have a factor of 10 startup time versus other 1.3.x versions.

Steps:

1. Download all the Cmder versions 1.3.0 to 1.3.6. This is the full installation packages, 7zip format.
2. Extract each 7z file to their own folder (I put it on my C drive).
3. For each version:
   1. Start up the application (just run the exe). This allows the app to initialise itself (I'm not testing this time).
   2. If it complains about an out-of-date dependency, go into the settings and disable the update check.
   3. Edit the vendor/init.bat file. Add the entry echo. | time to the very top (just below the @echo off) and to the bottom (just before the final main exit /b).
   4. Run the exe 3 times, recording the start and end times it displays, closing the app before starting a new one.

Notes about experiment:

• Only versions 1.3.0-1.3.2 complained about an out of date dependency, so they were the only ones to have a on-start update check disabled.

I performed this experiment on two different machines. Both run W10 October 2018.

1. My Home computer. A high-end desktop with rather good hardware. C drive is an M.2.
2. My Work computer. A slightly-better-than-"meh" laptop. C drive is an SSD.

This is the average startup time for each computer across each version, in milliseconds:

Cmder Version	Home	Work
1.3.0	463.33	1670.00
1.3.1	473.33	1593.33
1.3.2	466.67	1853.33
1.3.3	676.67	4533.33
1.3.4	666.67	4523.33
1.3.5	560.00	2260.00
1.3.6	1960.00	7173.33

Here are the graph versions for just home, just work, and both.

In the end, 1.3.6 is anywhere between 1.6 and 4.5 times slower than previous versions.

Version 1.3.6 is ___ times slower to startup than these versions:

Cmder Version	Home	Work
1.3.0	4.2	4.3
1.3.1	4.1	4.5
1.3.2	4.2	3.9
1.3.3	2.9	1.6
1.3.4	2.9	1.6
1.3.5	3.5	3.2

---

If there is any other information I can provide to help you figure out this slow down, please let me know. I really want this project to succeed.

[daxgames]

@gunr2171 Cmder 1.3.6 init.bat is doing more when it runs so it is a little slower we already know that. I doubt we can make it much faster without removing the additional functionality.

You can try this. It has been optimized for speed a little more than the released Cmder 1.3.6 and has a built in timer.cmd to time init.bat if the /t argument is specified in the ConEmu Task that starts init.bat.

Edit the Cmder task in this new build and add a /t to automatically time the init.bat. See the new task command below:

cmd.exe /k ""%ConEmuDir%\..\init.bat" /t "

Actual Sample Output from my system:

Elapsed Time: 0:0:1.81 (1.81s total)

C:\Users\user\cmderdev
λ

You can make it even faster by skipping git detection. Just add /GIT_INSTALL_ROOT %ConEmuDir%\..\git-for-windows to the task:

Elapsed Time: 0:0:1.36 (1.36s total)

That is better than my own Cmder 1.3.6 time posted above:

C:\Users\user\cmderdev(diags -> origin)λ timer 17:37:09.96 17:37:12.34
Elapsed Time: 0:0:2.38 (2.38s total)

If you want to you can also time other Cmder versions by:

Note: The /t argument is not supported or required on older Cmder versions if you follow the directions below!

Copy %cmder_root%\vendor\bin\timer.cmd into a previous Cmder install in the following location %cmder_root%\bin\timer.cmd.

Add the following to the top of the init.bat after @echo off:

set cmder_init_start=%time%

Add the following to the bottom of the init.bat above the last exit:

set cmder_init_end=%time%
timer %cmder_init_start% %cmder_init_end%

[daxgames]

@gunr2171 Cmder Fast Mode Init takes my init times from 1.81 down to .74 seconds.

[gunr2171]

Thanks for the new builds.

First results using only the /t flag, including retesting the official 1.3.6 build.

	Home	Work
1.3.6	2050	9048
1.3.6.765	2194	8028
1.3.6.781	2192	8490

Two things of note

1. The previous values for 1.3.6 I did before were 1960 and 7173 ms for Home and Work, respectively. I'm not sure why using timer rather than echo. | time added so much time (hopefully I didn't screw up something in Excel from last time).
2. 1.3.6 retiming were still faster than the dev builds (again, this is only using the /t flag).

I ran 781 with the /f flag as well.

	Home	Work
1.3.6.781 with /t /f	995	5552

Home went down a second, Work went down 3 seconds.

I'm going to keep playing with this at work to see if I can deal with a 5.5 second start up by sacrificing git recognition (because that's a feature I really like).

[daxgames]

I provided the timer.cmd and instructions so there would be a common standard way to test.

I have found in my optimizing this that startup times can vary widely from launch to launch, even on the two systems I have tested at home. The system I mentioned above I have seen 1.74, .94, .74, .72 seconds all on fresh launches and this new code.

The timer may add some time because it is actually doing calculation of elapsed time but should only add a few milliseconds. You can try just adding echo %time% to the top and bottom of vendor\init.bat but then you are not comparing apples to apples.

Your work PC probably has the added overhead and variability of IT department controlled AV, HIPS, and possibly some DLP software that can cause huge slow downs. That could account for the much larger jump in time on the work PC.

You can keep your Git and still us Fast Init Mode by adding /git_install_root [path] on the task command line. Note this is not Git discovery, rather you are specifying which Git install to use so it is faster than discovery.

[manatlan]

Thanks ! ...
I'm a new user of this marvelous tool ... the only things which bored me : it's the time between opening a new tab, and the prompt ready (more than 2sec ?! on a core i7 with 16go ram on w10 ?!?))
I tested the 1.3.5 : and it's now (just) "acceptable" ... I'll stick with it
Thanks for the tip !

[daxgames]

Closing since 1.3.8 was released with /f optimization