Extremely slow after the latest update to 1.15.0, Windows.

silvium commented 6 years ago

[x] I have searched open and closed issues for duplicates

Bug description

I'm not talking about the usual "Loading messages" that sticks around for minutes at launch. I gave up on that, i know it's a separate issue that needs probably $100 million to solve, since $50 million wasn't enough. I'm talking about Simply using it for what it was intended, chatting.

Steps to reproduce

Select a contact and wait for up to 2 minutes for the messages to load
Start typing a message
Watch as it doesn't type random parts of your sentence, doesn't cache them and continues registering the last words of the sentence as if nothing was typed in the meantime.

Actual result:

Expected result: words type out correctly. And your mission to help people in "censored countries" to actually apply. They are poor. They don't have the development machines you do, on which everything works smoothly. So stop feeling good about yourselves for that. And make a version for featurephones, that's what they afford.

Screenshots

Platform info

Signal version: 1.15.0 Windows

Operating System:

Linked device version:

Link to debug log

scottnonnenberg-signal commented 6 years ago

I understand that you're frustrated. You're right that we do use new machines for our development. But we can't do anything about your bug without logs and without more specific information, like your operating system and machine's hardware specifications.

babilon commented 6 years ago

I am experiencing similar slowness since 1.15.0. I have updated to 1.15.1 (a few hours ago) and the slowness (described below) is still present.

The desktop app for Linux becomes extremely sluggish, to a point where it freezes momentarily and CPU usage spikes (100+% on a multi-core AMD CPU) when sending messages in quick succession; the sluggishness is worsened when messages are arriving while actively typing and sending messages.

Here's my machine spec (uname -a): Linux purplerain 4.15.0-29-generic #31-Ubuntu SMP Tue Jul 17 15:39:52 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Recent log: signal_log.txt

lnicola commented 6 years ago

The desktop app for Linux becomes extremely sluggish, to a point where it freezes momentarily and CPU usage spikes (100+% on a multi-core AMD CPU) when sending messages in quick succession; the sluggishness is worsened when messages are arriving while actively typing and sending messages.

Does Signal have any animations? I've had similar issues in the Electron Skype app for Linux (which kinda' made me avoid Skype). I couldn't run Signal 1.15 yet, but maybe an option to disable animations would help here?

babilon commented 6 years ago

I'm not aware of animations in Signal. I don't see an option for such a feature either. I noticed this sluggishness immediately after upgrading from 1.14.4 to 1.15.0.

remusao commented 6 years ago

It's not as slow as described by @silvium but it became indeed much slower after the latest 1.15 update. Is there anything which we could provide to help investigate this issue further?

For me two things seemed to have changed after the update:

Closing the app takes a few seconds (longer than before)
More annoying is the typing speed, there is lacenty when typing in Signal now, which is a bit annoying. It did not "loose" any key-stroke so far though, it's just slow.

Should I send the debug log to someone?

scottnonnenberg-signal commented 6 years ago

You can always reach out to support@signal.org if you want to handle things privately.

dave000000 commented 6 years ago

I've been having the exact same problems as @remusao since the upgrade to 1.15.0. I'm running Debian Linux. Here are my specs according to uname -a:

Linux debian 4.9.0-7-amd64 #1 SMP Debian 4.9.110-3+deb9u1 (2018-08-03) x86_64 GNU/Linux

JiNova commented 6 years ago

Latency and diminished responsiveness is what I experience as well. Writing messages in quick succession while receiving messages at the same time makes Signal Desktop unbearable slow, rarely even character strokes get lost.

What I noticed is that the open conversation will display an "unread message" status in the conversation list on the left. This mark will then disappear, to reappear immediately and back and forth for a short time, even though no new messages have been received. I observed this behavior every time when Signal Desktop's responsiveness became very low.

Linux uname -a: Linux Limbus 4.14.60-1-MANJARO #1 SMP PREEMPT Fri Aug 3 12:49:45 UTC 2018 x86_64 GNU/Linux

scottnonnenberg-signal commented 6 years ago

For all who are running into performance issues, please consider providing your debug log. That will give us a chance to track down what's causing the problems. Thanks!

remusao commented 6 years ago

@scottnonnenberg-signal Thanks. I sent my debug log through the user support email with some more details. I think @babilon Already attached his own debug log to his last comment in this thread. Let us know if there is anything else we could do to help.

vbspam commented 6 years ago

I can confirm this issue also affects me.

Brief System Info

version: Signal-Desktop 1.15.4
os: Ubuntu 16.04 (most recent updates applied)
link to debug log: https://debuglogs.org/9080ac15a70df06c5d14d39a73129c3afaa95de8f27c1f809c7effac513fe3ff
signal-desktop cpu usage: 16-17%
free os memory: 8GB

Observation The latency started occurring after the app has been updated/upgraded; I noticed that it slightly changed its background color; and generally when the look&feel changed, but I can not describe what changed as I do not have the previous version available.

hkoller commented 6 years ago

I confirm this also affects me and is still present in signal 1.15.5. As vbspam observed, the issue started after one of the last updates (not long ago, when the look&feel changed slightly)

System Info:

Signal version 1.15.5
OS: Kubuntu 16.04.5 LTS (most recent updates)
link to debug log: https://debuglogs.org/6aa007a59c0f2a4df53dfee2a35fa9bc7ceb78fbd931c5a8d149efe5b3cbee79

Dafnik commented 6 years ago

I'm also having huge performance issues

System Info:

Signal version 1.15.4-beta1
OS: KDE Neon (Ubuntu base 16.04.5 LTS latest)
Debug log: log

scottnonnenberg-signal commented 6 years ago

@Dafnik @hkoller Thanks for the logs. It would help if you could talk about what exactly feels slow. Is it overall startup of the app? Or opening a specific conversation? Or other specific scenarios? What really helps narrow down the investigation.

babilon commented 6 years ago

@scottnonnenberg I'm still experiencing the sluggishness in 1.15.5 as I described earlier.

I have a conversation window selected. I'm typing a message out. The same contact has sent a message (or multiple) and more are coming in as I'm typing a message.. While still trying to type my own message out, the app freezes, my keyboard inputs are not rendered in the conversation window. If I let the app be for 10-30 seconds (this time required varies), the app usually renders the rest of the message I had typed out.

On other occasions, I have sent 2-3 messages, while the other contact has or will soon have sent a similar number of messages. After I've hit enter, to send a message, and begin immediately typing another, the first half dozen or so keystrokes are lost. My message might have been "check the mail" and turns into "he mail". This case happens usually when messages are incoming while I'm beginning a new message.

The more messages exchanged in quick succession, the slower the app becomes. Until messages stop flowing; then things return to normal responsiveness.

scottnonnenberg-signal commented 6 years ago

@babilon Thanks for the details of what you're experiencing. A recent log would be really helpful, since quite a few updates have happened since you last provided one.

babilon commented 6 years ago

@scottnonnenberg Here's a current log from the same machine I posted from earlier.

I use signal-desktop on two computers (same OS; only difference is laptop with Intel CPU and desktop with AMD CPU). Earlier today, signal-desktop on the laptop seemed to have hung up during start up while downloading/syncing messages so I cleared all data. Since then, I had not run into the slowness issue. I have not cleared data on the desktop which the log linked below is from; I have experienced the slowness issues since 1.15.5 on the desktop so hopefully the log has something of use.

Maybe clearing all data since 1.15.X is the solution... I will watch for trouble on the laptop and post a fresh log from it if I run into the slowness on it again. I might just clear data on the desktop's install of signal-desktop too.

Signal-desktop 1.15.5 log from desktop machine (specs posted in previous comment): https://debuglogs.org/3d226f985a668a7bcb2ef7a5aa04a96b786fdd58404d5578381b38d22b7035b6

babilon commented 6 years ago

FWIW, after clearing all data on the desktop machine, have not experienced a slowness issue (yet). Maybe after the debug log has a 10+ thousand lines in it...?

lnicola commented 6 years ago

After managing to update to 1.15 (the flatpak version, I wanted to post here saying that I don't see any extra slowness, but after a couple of days they cropped up.

As far as I can tell, there are two different issues:

loading the application is slower than before
typing starts fine, but gets slower after a while

I think this issue is mostly about the latter, but I'll write here about both of them. Note that I'm on a reasonably fast laptop (i7-6700HQ, 16 GB RAM, Intel graphics, SSD, Linux). Signal is much slower than other programs.

Loading

Signal seems to have three stages for loading:

first it's saying "Loading messages..."
then a throbber starts spinning (the three circles animation)
then it starts counting messages, 10 at a time

I have other devices running Signal, but this is the fastest one. I tend to leave it running, sometimes during sleep, so it does have a bit to sync.

What I noticed:

the first stage was fast before, but feels slower after updating from 1.15.0 to 1.15.5. It's not always slow, maybe only when there are more messages to be synced. So on most start-ups it's unnoticeable, but when it's slow, it can take 30 seconds or so.
the second stage is similar to the first one in behaviour, but maybe a little faster
the third stage was always slow, and there are probably other issues open for that; it used to take most of the start-up time. Before upgrading to 1.15.0 it was loading say 10 messages every two seconds or so. In 1.15.0 it got slower, maybe 10 messages every 10 seconds. Then in 1.15.5 it got faster again (similar to 1.14), at the expense of the first two stages. I think this is the sync phase, but it used to be erratic (it counted messages -- fewer -- even when restarting it just after a sync), but that might have been fixed in 1.15.0.

Here is a debug log from this morning, after closing and restarting Signal. The first stage was 30 seconds, if not longer (just my memory, I didn't try to check that against the log). I'll probably remove the link after you acknowledge reading my post (@scottnonnenberg-signal).

I also took a random screenshot during the second or third stage; the GNOME compositor doesn't like animations in Electron apps, but I already knew that.

I don't know how Signal works, but seven minutes for loading seems a bit excessive, even for a JavaScript app. Is there some kind of batching that's missing or could be improved?

As a final note, I think the sync phase (third stage above) also happens for messages sent from other devices even if Signal was left running. So it already displays all messages, but restarting it still takes a couple of minutes. That seems wrong.

Typing

The main issue here, I suspect. Signal is fast at first, but after a couple of hours (days?) it gets very slow. It's fast again after a restart. When typing, the letters take seconds to show up, sending and receiving messages is similarly slow.

I have two theories here:

scrolling might be slow in Electron 2 (not sure about 1). Even scrolling through my debug log was slow for me.
there is exactly one other web site where I encounter exactly the same issue after maybe two or three screenfuls of conversation and I need to refresh the tab or even restart my browser; can you guess it? It's Facebook Messenger (the full-screen one). This never happened to me in Signal before 1.15.0.

So I blame React. But you probably won't find anything about that in the logs people are posting here. Is there a way to start the Chrome profiler in Signal? But I'm pessimistic about it -- Facebook could never make it fast, and they're the developers of both Messenger and React.

Sorry for the wall of text, but I hope this sheds some light on the issue.

Dafnik commented 6 years ago

@scottnonnenberg-signal My main problem is when I'm in an ongoing conversation. When I type a message and sometimes directly after hitting enter I want to reply (in the same chat) to another message it's really lagging (the input is not rendered in real time, selecting another chat is slow and lagging) and if my chat partner is also sending messages to me in the same time the effect is only worse. I hope that could help.

lnicola commented 6 years ago

@Dafnik Does restarting Signal alleviate your problem for a while? Or is it slow right from the start?

If you have used Facebook Messenger in a browser, did you notice any similar slowdowns there?

Dafnik commented 6 years ago

Yeah it feels like it's better after restarting. I only have Discord next to Signal installed but there I haven't experienced such problems.

vbspam commented 6 years ago

No is still same slow here v1.15.5. .

It looks that the slowness is somehow time of day related (heavy lunch issue? :-) ).

I thought it is network related, however Wireshark did not revealed any network IO when typing messages.

On 08/20/2018 02:41 PM, Dominik wrote:

Yeah it feels like it's better after restarting. I only have Discord next to Signal installed but there I haven't experienced such problems.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/signalapp/Signal-Desktop/issues/2613#issuecomment-414303082, or mute the thread https://github.com/notifications/unsubscribe-auth/AXJvdRwUmOfIT0GtrV9wCBp9T2zyDmCnks5uSq6PgaJpZM4VvS-r.

remusao commented 6 years ago

I will just add my two cents here. In my case it does not seem to get better after restarting, although it is faster before sending or receiving any message (so when I start the app and start writing my first message, it's fast), but after I send the first message or if I start receiving a message it slows down the app by a lot. So the action of receiving/sending (or a side effect of that) seems to be slowing down in my case.

babilon commented 6 years ago

Here's another log.. same machine.. after clearing all data 4 days ago, performance is poor again. https://debuglogs.org/8dc244d89f0ba711f6c538fa7ac75db8cd81e30dc06b37abe84965671116a3ca

nehresma commented 6 years ago

Same thing here on Linux (1.15.5). Key presses noticeably lagging. Sometimes up to 10 seconds. Restarting Signal fixes it for a while. Quad core i6700k with 32 gigs of ram. It isn't resource constraints causing the lag.

crabdancing commented 6 years ago

Here to confirm the issue. uname -a output: Linux lithium 4.18.2.a-1-hardened #1 SMP PREEMPT Fri Aug 17 22:53:33 CEST 2018 x86_64 GNU/Linux

Signal typically at 3% CPU usage, with 5% RAM usage. This is not an issue with limitations in Signal's resources. I have a decent quad core i5 CPU and 12GB of RAM. But the GUI is unusuable, sadly. I'll have to downgrade until this is fixed!

Update: rather irritating to discover the Signal updates repo for Debian systems has HTML browsing disabled. Would have been rather useful for someone trying to modify an AUR script to build an Arch Linux package from the .deb... >.>

Another update: Turns out, v1.15 reformatted the local signal logs on my laptop... so I had no choice but to just squirrel away everything in the Signal backup file and resort to deleting every log past 100 messages. Which appears to have fixed the lagging problem. So it looks like the problem with 1.15 is that none of your testing is done with large log files! Some routine is too inefficient and it makes the app super laggy when you have, e.g., 30k messages stored. That's my guess. I'd give my log file, but it didn't seem to contain any important information and I see plenty of other people giving theirs. Let me know if any other info about my experience or setup is needed to help with troubleshooting.

Update: it has slowed down again after accumulating only a day or so of logs. I'm downgrading and staying downgraded until this gets fixed. :P

babilon commented 6 years ago

FWIW, I've been using the beta 1.15.5-beta1 since August 22, so about 2 days, and by now, it's showing similar/identical performance issues as the current non-beta during those frequently exchanged message conversations..

babilon commented 6 years ago

Here's a log from the beta: https://debuglogs.org/7b7ca15c352d9d2cb101880cd95dd4ea5525df45c2a75b1f909a5eef3fe4a592

stevesbrain commented 6 years ago

I am having the same kind of issues as @babilon - i.e. the main slowness/freezing happens whilst receiving messages at the same time as typing them out. If it is still useful, I am happy to provide debug log. Can also provide massif or sysdig captures if helpful/required - just let me know!

scottnonnenberg-signal commented 6 years ago

Thanks everyone for weighing in on this. I have a fix ready for our next beta release which should address the typing slowdowns while you are receiving messages. I'm not sure that it will address the general issue of things slowing down over time, but I suspect that they may be closely related, if not the very same issue (after all, you aren't usually receiving messages right after you start up). We'll have to see!

stevesbrain commented 6 years ago

@scottnonnenberg-signal Awesome - thanks for your work :D May I ask what the issue was (or are you able to reference a commit it was fixed in)? I'm curious :)

scottnonnenberg-signal commented 6 years ago

@stevesbrain I modified the binary->JSON conversion we have to do before we put every incoming message into our SQLCipher cache. This is because it's a synchronous operation, and would block the main UI thread. In this change I moved it to a different thread: https://github.com/signalapp/Signal-Desktop/commit/02fbea96c0b1a54509958d7b311e4febd0eb8b28

stevesbrain commented 6 years ago

Appreciate the explanation - thanks :)

strotter commented 6 years ago

I see a potential fix is in the works, but I'd like to chime in and say I have the same experience with 1.15.5 still currently. The only real temporary fix I've found is to completely reset/clear data and re-scan the QR code to start fresh. But it's becoming tedious doing it every 24-48 hours. There are times when the window won't respond for 20-30 seconds even, much less register my keystrokes.

It's strange that the JSON conversion works fine for many hours on a new installation, but degrades heavily over time.

model name : Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz Linux sky 4.15.0-33-generic #36-Ubuntu SMP Wed Aug 15 16:00:05 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

scottnonnenberg-signal commented 6 years ago

@strotter The more information you provide, the better. Debug log is the best, then a description of how you use the app, and if you're not willing to provide debug logs some discussion of your incoming/outgoing message frequency.

strotter commented 6 years ago

@scottnonnenberg-signal Sure thing.

There are around three contacts that I'm frequently messaging more than the others. I type quickly, messages can be somewhat short, effectively similar to SMS in length but more overall messages. Dozens per minute sometimes.

https://debuglogs.org/78e1e6022cffdcef02951782a9ac0f22d736effaa384e86dc8947bd985c4b07f

Here's the debug log, I had fully reset all data and reconnected to the desktop via QR code and started fresh. On the 28th there was no lag. As of today, extreme lag (non-deterministic, it happens randomly and I can't pinpoint any specific behavior that may be triggering it, sometimes it just stops responding even if no messages are coming in at all.) It's not related to switching chat windows between people either, that I can tell.

I've also attempted to fully delete all chat windows individually, but it doesn't seem to help the same as going into preferences and clicking "clear data" to wipe everything out from scratch.

I've also noticed that a complete "clear data" wipe is still far more effective than closing/re-opening the desktop app.

Hopefully this helps. I wouldn't mind contributing or testing if you can point me to any dev docs on how to do performance profiling (I can write ES6, but I haven't used electron yet.)

lnicola commented 6 years ago

@scottnonnenberg-signal In a comment above I posit that this might be a front-end issue caused by React, on the basis of similar performance issues; maybe trying out the Chrome profiler would give more information here?

babilon commented 6 years ago

I've been using the v1.16.0-beta.1 for several days and experiencing the same sluggishness, lost key presses as before, high CPU use. Description by @strotter is accurate for my use and experience as well.

Linux greenrain 4.15.0-33-generic #36-Ubuntu SMP Wed Aug 15 16:00:05 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Here's current log from the machine mentioned above (uname -a) https://debuglogs.org/696d560b268ee9d1f9affc2467bd3e1df353a0676b05267397f367e3f9590ec4

strotter commented 6 years ago

Same for me @babilon .. CPU usage goes so high during lock periods that my CPU fan hits max speed for about 10+ seconds. Only signal desktop causes my CPU fan spikes, not even my virtualbox virtual machines cause that sort of spike.

scottnonnenberg-signal commented 6 years ago

@babilon @strotter Many thanks for jumping in and using the beta! Now, for some details. When do these 'lock periods' happen? When you receive incoming messages? When you send messages? When you scroll? In your provided log, @babilon, I didn't see any obvious case of big delays - I'll need information from you to help kick-start the investigation.

You say lost keypresses - is that after you've sent one message and are trying to type the next? Or just typing any message? Are new messages arriving when you lose keypresses?

And again: what is happening in the app when you see High CPU usage? Receiving messages, sending them, starting up the app, reconnecting after being offline, what exactly?

Also, In the future, please include lsb_release -a in addition to the uname information.

babilon commented 6 years ago

@scottnonnenberg here's lsb_release -a output:

$ lsb_release -a
No LSB modules are available.
Distributor ID: LinuxMint
Description:    Linux Mint 19 Tara
Release:    19
Codename:   tara

The lost keypresses occur after a few days of use (so maybe the log has grown to substantial size) and while I'm typing multiple messages in quick succession; messages are brief, less than a dozen words, typically at most 6 words, sometimes less per message. I'd type a message out, press enter key, immediately begin typing another one, hit enter.. I do this for 3-4 messages and things start slowing down. The recipient is also sending messages, but at a slower rate.. So I may have sent 2-3 and they sent one..

Also, after clearing the log (about 3 hours ago), and sending a quick splash of messages to the recipient, I experienced no slow down. The recipient was AFK and did not reply during that test.

When high CPU usage occurs, the app is .. frozen, or just about. it's not rendering anything for a moment a second or two. and then the app renders some of my key presses, and some messages that were sent by the recipient arrive and display. I typically have the desktop app running for hours at a time without restarts. Network remains connected long enough that I don't notice disconnects (no notifications that wifi/ethernet has gone down). The messages are synced at the same time to my android phone.

New messages may be arriving when key presses are lost.. I think I have seen this happen. As in, the app usually slows to a complete halt, I stop typing because I don't see my message typed out, I wait, then text I typed renders in the entry box, a message from the recipient arrives, maybe I pressed enter and finally that half complete message is sent.. It's a fuzzy mess...

I will do my best to elaborate more details later. And collect more intel the next time this happens.

scottnonnenberg-signal commented 6 years ago

@babilon Thank for the additional detail. When you say that you 'cleared the log' what does that mean, exactly?

babilon commented 6 years ago

@scottnonnenberg File -> Preferences -> clicked Clear Data button. Then I relinked to my phone..

strotter commented 6 years ago

There is no pattern. The CPU spikes are random. I have attempted to replicate it to no avail, it just always hits out of nowhere.

lsb_release:

Distributor ID: Ubuntu Description: Ubuntu 18.04.1 LTS Release: 18.04 Codename: bionic

For what it's worth I also use Atom and vscode quite a bit and never experience the typing lag/CPU spike in them.

babilon commented 6 years ago

@scottnonnenberg Follow-up with more details...

I frequently message one contact significantly more than others. I typically encounter the sluggishness while messaging this contact first, probably due to the frequency and amount of messaging. I do encounter the sluggishness with other contacts but I don't think I notice or become bothered enough by the sluggishness to Clear Data. For this contact, I have disappearing messages enabled, set to 1 day. I have "Read receipts" enabled. This particular contact does NOT have the "Read receipts" feature enabled. Other contacts I frequently converse with do have this feature enabled. I have disappearing messages enabled for most of my most active conversations. I installed v1.16.0-beta.1 two days ago (as soon as I noticed Mint reported it was available, I updated). I did not Clear Data before updating to this latest beta; so the log had some pre-existing data from the previous beta, 1.15.5-beta.1. I ran Clear Data shortly after posting my comment of using the 1.16.0-beta.1. Signal Desktop was sluggish leading up to the time I posted that comment. Looking at the log, I see some triple digit times in ms ... assuming these times are indicative of how long an action took to complete; I would say these longer times align with the moments when the application become extremely sluggish and CPU usage spiked.

During these spikes the contact and I were exchanging messages; I would be typing a message, press enter, a message may have been coming in as I pressed enter. I would have been already starting to type a follow up, ... The lock ups might have been during an incoming message being rendered; the counter of unread messages may have flashed and gone away since I had focus to that same conversation. The CPU spikes (and increase in fan speed) definitely occurred during these active conversations and seemed to be sustained if our back and forth conversation continued. I think, recollecting from memory, if I were the only one sending messages, even in quick succession, the app would not hit these CPU spikes and lock up and sluggishness - or at least not as severely... To hit the performance issues, the recipient was engaged in the conversation.. sending messages, etc.

These log entries and groups of others with similar large times look interesting. Many times are under 10ms; but there are several groups of triple digit times..

INFO  2018-08-31T15:40:54.828Z SQL channel job 9249 (getMessagesByConversation) succeeded in 24ms
INFO  2018-08-31T15:40:55.579Z SQL channel job 9250 (saveMessage) succeeded in 774ms
INFO  2018-08-31T15:40:55.674Z SQL channel job 9251 (getUnreadByConversation) succeeded in 851ms
INFO  2018-08-31T15:40:56.335Z SQL channel job 9252 (getMessagesByConversation) succeeded in 755ms
INFO  2018-08-31T15:40:57.034Z SQL channel job 9253 (getNextExpiringMessage) succeeded in 9ms

strotter commented 6 years ago

I've been using the new .16 version for a while now... and I'm still getting huge spikes. Sometimes I can't type for 20-30 seconds at a time still (similar behavior to the .15 series.) The typing lag seems minimally improved, but still exists.

What I don't get is that none of these performance problems existed before. I only had to clear out signal every 3-4 months, not every 3-4 days. I wish I could help in profiling where the CPU hangs are occurring.

And FWIW the signal process goes 100% CPU on one core and makes my fan spin on max. (EVO 212, still fairly quiet but signal is the only application that makes it spin on max.)

stevesbrain commented 6 years ago

Unfortunately 1.16 is actually worse for me - I get 100% CPU spikes (for a single core) when sending now also :(

I appreciate that these can be extremely difficult to debug, etc. Please let me know if this is not an issue you are already working on, and I'll provide whatever I can to assist :)

babilon commented 6 years ago

Came here to say that v1.16.1-beta.1 has been working wonderfully the past 2 days (since this beta became available). I have experienced a few sporadic momentary (couple seconds at most) freezes of the app. The sporadic freezes were AFAICT just that: random. There were no messages incoming while I was typing a message and signal froze a moment.. I may have sent some messages in quick succession like the past but I don't have a pattern to explain this behavior.

Overall... this one is working MUCH better than the previous.

I forgot when I last cleared all data. There may be something else to be said after a week of using this. I'll update in some time.

scottnonnenberg-signal commented 6 years ago

@strotter @stevesbrain Have you been able to try v1.16.1-beta.1? As @babilon mentioned, it does have additional performance enhancements.

signalapp / Signal-Desktop