Slow startup

[trudnorx]

Startup noticeably takes many more seconds in the newer snapshots. Went from near-instantaneous to a clear feeling of "slow". This happens even after repeatedly starting it so caching isn't helping.

[davidebeatrici]

Could you try to disable the public server list to see whether it makes a difference, please?

[trudnorx]

Public list was always disabled.

[davidebeatrici]

Are there enabled plugins?

[trudnorx]

None.

[trudnorx]

Happens even when disabling checking for updates & enabling "do not send OS info..."

Does it start slowly in your system? (Slowly should be defined as anything above 0.1 seconds which is how fast old Mumble loaded). If not, try on Windows. Maybe it would help to profile the app, see what it's stuck on.

[trudnorx]

Seems like the slowness occurs between the messages "CELT bitstream 8000000b from ...celt0.0.7.0.dll" and "Theme: Mumble" being outputted to debug.

[Krzmbrzl]

Are you perhaps using a Debug build of Mumble?

[trudnorx]

I just got one of the snapshots. The older snapshots I tried were working pretty fast so I don't understand why this one would have slow start-up unless something changed. Could be an issue present in the release build too. I used Mumble-1.4.0~2021-05-16~g789f2d7~snapshot.x64 And why would start-up be slow but the app is otherwise fast?

[Krzmbrzl]

I just got one of the snapshots.

Alright that means that you are using a release build :+1:

The older snapshots I tried were working pretty fast so I don't understand why this one would have slow start-up unless something changed.

So up until snapshot 5 the startup was fast but with snapshot 6 it got slow?

[trudnorx]

I switched from a months-old snapshot to the newest one. Old was fast, new is slow.

It's not like it takes minutes to start, but old version took like 0.1 seconds (my perception) to start and new version takes 5+ seconds. Sufficient for it to feel annoying to the end user.

[Krzmbrzl]

I switched from a months-old snapshot to the newest one. Old was fast, new is slow.

Any chance you could figure out which snapshot the old one was? We had releases on

• 16.05.2021 Snapshot 6 (most recent)
• 07.05.2021 Snapshot 5
• 03.04.2021 Snapshot 4
• 21.03.2021 Snapshot 3
• 26.02.2021 Snapshot 2
• 24.12.2020 Snapshot 1

[trudnorx]

I don't think I can figure it out since I deleted it, but in any case it doesn't seem like relevant information, since the fact is that multiple old versions of Mumble (including 1.3.0) were starting fast in my machine. So, that it went from fast to slow is a given. Even if we figured out the snapshot I was using, that was months-old, so it would still not help that much in finding what change made it slower. I think it's better to investigate: why is there a long pause in between the messages "CELT bitstream 8000000b from ...celt0.0.7.0.dll" and "Theme: Mumble" being outputted to debug? Whatever the program is doing in between outputting these two messages -- that's where the slowdown is and what's causing the slowdown. Also, how many seconds does the snapshot take to start in your machine? How many seconds does an old version of Mumble, e.g. 1.3.0., take to start?

BTW: I tested it in another Windows computer. Windows 7. Same result. New version is slow. Old versions of Mumble were fast in that machine too, before.

[Krzmbrzl]

The information which snapshot worked and which does not reduces the amount of possible commits that might have introduced an issue significantly. This is not about me doubting that the startup has become slow, this is me trying to get closer to the cause of the issue.

So if you could estimate how old "months old" is, that could help. Do you perhaps remember which feature was new when you installed the previous snapshot?

[trudnorx]

I'm not saying you're doubting it, I was just curious if you could reproduce. I don't remember anything about it. Could have been even a snapshot earlier than the 'official' release series you listed. Like by building directly from git. All I know is that a) this snapshot, b) 1.3.x, and c) versions of Mumble older than 1.3.x, all three of these, all were working fast. Now there's slow startup with the latest snapshot.

[Krzmbrzl]

Ah okay too bad ^^

I haven't actually tried to reproduce. I am usually running a debug build anyways in which case there is a noticeable delay before Mumble starts. As far as I can tell that has not increased significantly but I usually don't focus on it anyways so that might not be true.

I am doing a release build now in order to check :)

[Krzmbrzl]

Yes I can reproduce the delay. To me it seems that the delay is coming from loading ALSA (or rather: trying to do so).

Between the CELT bitstream and the Theme message I don't see any noticeable delay though :thinking:

[trudnorx]

Interesting. So perhaps there is a different delay on Linux systems and Windows. It can't be loading ALSA on Windows. (and if it is trying to do so it should be stopped!)

Try on Windows. And see if it's between CELT and Theme on Windows.

[Krzmbrzl]

Try on Windows. And see if it's between CELT and Theme on Windows.

I can only test in a VM that I feel is a bit slow anyways. But I can try anyways. But that will take a bit since my VM has run out of space and because Windows is silly it does not allow me to enlarge my partition even though I increased the virtual disk's size :roll_eyes: Aka: I'll have to set up a new one

[davidebeatrici]

Even from the Disk Management dialog?

[MadDeydey]

Hi,

I also show that 1.4.x version take a few seconds to launch on Windows computers. It happens with snapshots and homemade builds. I couldn't tell when it has started but in January 19th (my oldest 1.4 build), the problem seems to be present.

After comparing logs between 1.3.4 & 1.4.0, this line seems to be present only in 1.4.0 : "QMetaObject::connectSlotsByName: No matching signal for on_qtvUsers_customContextMenuRequested(QPoint,bool)"

I hope it could help... @trudnorx, can you see the same log output?

Even from the Disk Management dialog?

To complete : don't forget to refresh the disk management window ;) don't know why but it won't do it automatically...

[Krzmbrzl]

Even from the Disk Management dialog?

Yeah. Windows decided that it needs a recovery partition right next to the main partition and that causes unallocated space to not be in direct neighbourhood of the main partition which is a requirement for growing partitions. And it also won't let me delete the recovery partition 🤷

In any case though I have a new VMup and running now, so I should be able to test this soon...

@MadDeydey I think the slot message you are seeing is unrelated :thinking:

[davidebeatrici]

Heaviest stack for the main thread of the target process:
  10  start + 1 (libdyld.dylib + 89917) [0x7fff20331f3d]
  10  main + 10609 (Mumble + 183297) [0x10c3eec01]
  10  QApplication::~QApplication() + 834 (Mumble + 3079330) [0x10c6b1ca2]
  10  QObject::~QObject() + 284 (Mumble + 18521868) [0x10d56bf0c]
  10  void doActivate<false>(QObject*, int, void**) + 1458 (Mumble + 18552722) [0x10d573792]
  10  QDnsLookupThreadPool::_q_applicationDestroyed() + 19 (Mumble + 10377043) [0x10cda7753]
  10  QThreadPoolPrivate::waitForDone(int) + 83 (Mumble + 17022435) [0x10d3fdde3]
  10  QWaitCondition::wait(QMutex*, QDeadlineTimer) + 83 (Mumble + 17030355) [0x10d3ffcd3]
  10  QWaitConditionPrivate::wait(QDeadlineTimer) + 59 (Mumble + 17030459) [0x10d3ffd3b]
  10  __psynch_cvwait + 10 (libsystem_kernel.dylib + 15694) [0x7fff202e3d4e]
 *10  psynch_cvcontinue + 0 (pthread + 21269) [0xffffff80035d7315]

Probably a Qt bug.

[Krzmbrzl]

@davidebeatrici how exactly did you test this and does heaviest mean longest here?

[davidebeatrici]

I got the trace by launching Mumble on macOS without internet access.

[Krzmbrzl]

does heaviest mean longest here?

:point_up: (Instead of heaviest meaning most CPU intense)

[davidebeatrici]

Sorry, I'm actually not sure. It seems like it's something specific to macOS.

[JuniorJPDJ]

<offtopic>

Even from the Disk Management dialog?

Yeah. Windows decided that it needs a recovery partition right next to the main partition and that causes unallocated space to not be in direct neighbourhood of the main partition which is a requirement for growing partitions. And it also won't let me delete the recovery partition shrug

You can delete this recovery partition using diskpart

select disk N
select partition N
del par override

</offtopic>

[JuniorJPDJ]

@trudnorx can you check if #5159 makes it fast again?

[Matthaiks]

Startup is slower again with v1.5.517 RC (Windows 10 x64).

[Krzmbrzl]

@Matthaiks also after repeated startups? And did you verify that this is not Windows trying to scan the application for malware or something like that?

[Matthaiks]

Yes, many startups with Defender disabled. Also with the clean Mumble settings.

[Krzmbrzl]

@Matthaiks sorry for the super late response, but how slow is "slower"? I was now able to compile Mumble on an actual Windows machine and I could not observe any noticeable delay between me clicking on the exe and the UI popping up :eyes:

[Matthaiks]

@Krzmbrzl ~1 second vs ~5 seconds.

[Krzmbrzl]

Hm. I just tested this and 1.5.517 does indeed seem to take longer for starting up 🤔