[Mac specific?] Start-up speed of Wx version

[singalen]

On a fairly new hardware (2.9GHz i7 MacBook Pro 2016), a cold start of a GUI version takes 3-4 seconds, a warm start - about 1s.
It would be really nice to reduce the time.

[elfmz]

can it be that your wx compiled in debug flavour?

[singalen]

It's wx installed from MacPorts. Hardly.
I'll profile it when I can.

[elfmz]

As i understood from topic, staring far2l --tty in terminal works much faster, correct?

[singalen]

In fact, I never tried it. tty launch was not super-fast either, it took something under 1s.

[elfmz]

cold or hot?

[singalen]

Hot.
A quick profiling shows the following as the heaviest stack trace:

  15  507.0  far2l (90323) :0
  14 libsystem_pthread.dylib 242.0  thread_start
  13 libsystem_pthread.dylib 242.0  _pthread_start
  12 libwx_baseu-3.1.dylib 239.0  wxThreadInternal::PthreadStart(wxThread*)
  11 libwx_baseu-3.1.dylib 239.0  wxThread::CallEntry()
  10 far2l 239.0  WinPortAppThread::Entry()
   9 far2l 239.0  FarAppMain(int, char**)
   8 far2l 233.0  MainProcessWithInterThreadCallsDispatching(UnicodeString&, UnicodeString&, UnicodeString&, int, int)
   7 far2l 212.0  ControlObject::ControlObject()
   6 far2l 169.0  ReadConfig()
   5 far2l 135.0  FilePositionCache::Read(wchar_t const*)
   4 far2l 107.0  GetRegKey(wchar_t const*, wchar_t const*, UnicodeString&, wchar_t const*, unsigned int*)
   3 far2l 101.0  WINPORT_RegQueryValueEx
   2 far2l 99.0  CommonQueryValue
   1 libsystem_c.dylib 70.0  fopen
   0 libsystem_kernel.dylib 69.0  __open_nocancel

but it doesn't explain the whole time it takes.
I'll try to do more profiling later.

Maybe it has something to do with 2700 files in my REG directory...

[elfmz]

Check on branch investigate-910. Note that its not very tested, just rough initial code to check.

[singalen]

Feels ways faster!
Dunno what will happen when I accumulate a similar amount of edited files cache.

[elfmz]

Check now if it became even better. I moved highlighting data to ini file

[elfmz]

Plz note that on 1st run it will still use registry, so take into account only 2nd+ runs

[singalen]

Subjectively, I cannot see the difference between 18a1bd8 and be944a9. I can measure the startup time precisely, if you wish.

BTW 18a1bd8 tends to crash on exit with:

Thread 11 Crashed:
0   libsystem_kernel.dylib        	0x00007fff687e833a __pthread_kill + 10
1   libsystem_pthread.dylib       	0x00007fff688a4e60 pthread_kill + 430
2   libsystem_c.dylib             	0x00007fff6876f808 abort + 120
3   com.far2l                     	0x00000001069e50b1 InvokePrevSigaction(int, __siginfo*, void*, sigaction&) + 897
4   com.far2l                     	0x00000001069e4d16 SafeMMap::sSigaction(int, __siginfo*, void*) + 310
5   libsystem_platform.dylib      	0x00007fff688995fd _sigtramp + 29
6   ???                           	0x2d02ef8d5a05df1b 0 + 3243418072039939867
7   com.far2l                     	0x000000010697a11f FilePositionCache::~FilePositionCache() + 63
8   com.far2l                     	0x000000010689d014 ControlObject::~ControlObject() + 356
9   com.far2l                     	0x0000000106953076 MainProcessWithInterThreadCallsDispatching(UnicodeString&, UnicodeString&, UnicodeString&, int, int) + 2406
10  com.far2l                     	0x0000000106953ef0 FarAppMain(int, char**) + 2912
11  com.far2l                     	0x0000000106872663 WinPortAppThread::Entry() + 19
12  libwx_baseu-3.1.dylib         	0x000000010737d52c wxThread::CallEntry() + 30
13  libwx_baseu-3.1.dylib         	0x000000010737cf8e wxThreadInternal::PthreadStart(wxThread*) + 1740
14  libsystem_pthread.dylib       	0x00007fff688a5109 _pthread_start + 148
15  libsystem_pthread.dylib       	0x00007fff688a0b8b thread_start + 15

[elfmz]

Yes there was bug, just fixed.
Check if ~/.config/far2l/highlight.ini created. If its not there - do Shifrt+F9 to save settings and check next start time

[singalen]

Yes it is.
Thank you very much!