Extremely slow performance since upgrade
-
@RasheedHolland said in Extremely slow performance since upgrade:
The only one who is deceiving anybody is you, you act like you are a seasoned troubleshooter, but you're not. The only thing you can do is to advice people to uninstall security software, but you seem to have zero knowledge about the inner workings of HIPS software. I advice you to stop trolling, and go find another hobby.
Personal attack instead of answering questions or providing testable hypotheses and reproduction.
You are you not responding to the arguments about doubt being productive and as I expected ego gets involved and attack me.
Where did you post you about disabling the shields of multiple security programs? Having multiple security programs running concurrently can produce complex interactions.
In the end all we want is a testcase that provides reproducible results.
-
@EricJH said in Extremely slow performance since upgrade:
@RasheedHolland said in Extremely slow performance since upgrade:
The only one who is deceiving anybody is you, you act like you are a seasoned troubleshooter, but you're not. The only thing you can do is to advice people to uninstall security software, but you seem to have zero knowledge about the inner workings of HIPS software. I advice you to stop trolling, and go find another hobby.
Personal attack instead of answering questions or providing testable hypotheses and reproduction.
You are you not responding to the arguments about doubt being productive and as I expected ego gets involved and attack me.
Where did you post you about disabling the shields of multiple security programs? Having multiple security programs running concurrently can produce complex interactions.
In the end all we want is a testcase that provides reproducible results.
Do you remember how this discussion all started? You asked me if I had tried a couple of the suggestions made by others, and I told you I did, and then you started to attack me, that you had difficulty believing this because of my writing style, or something like that.
But anyway, I already told you twice that I'm not interested in your advice anymore, because I don't take you seriously, because of your lack of technical know how. Yet you continue to respond.
So let's make a deal, forget about me, SpyShelter and your damaged ego. And try to solve the problem for at least one person in this thread. And if you can't solve it, at least come up with useful information for developers, which will perhaps help them to solve the problem. Who knows, perhaps you can prove me wrong, that you're not actually a troll.
-
@Ayespy said in Extremely slow performance since upgrade:
@RasheedHolland said in Extremely slow performance since upgrade:
Flawed reasoning? You have to be kidding me. What I'm trying to explain is that this hasn't got anything to do with Vivaldi not being trusted after upgrade, HIPS are smart enough to alert you about this.
Not kidding you. Accurate observation and the accuracy of reasoning are my profession. Troubleshooting requires data, data requires observation, and observation requires experimentation. It is impossible to troubleshoot by argumentation, "logic," or winning arguments.
If you desire to troubleshoot the problem that you are having, you can do all of the necessary steps without "reasoning" why some are unnecessary or inapplicable. Consider this: If you have a problem and I don't have a problem, what, exactly, shall Vivaldi developers change to remove your problem? What, exactly, caused it? Can you prove it? More to the point, can testers prove it? That is the only productive discussion that can be had here.
Yes I agree, at least partially. But the question is if certain steps are necessary in the first place. So I'm afraid, reasoning is needed, in order to avoid performing pointless steps.
For example, all security tools can cause problems in theory. Should we all remove Windows Defender? Or should we switch to another third party AV? Perhaps the people running Win 10 should simply upgrade to Windows 11? Should we perhaps remove all of the installed Windows updates, to see if this makes things better? Or should we buy a new machine with a newer CPU/GPU? Or is it perhaps a better idea, if developers gave an option to disable this Portals feature, which was a major design change in Vivaldi 6.2? This would perhaps save us a whole lot of time.
-
@Ayespy said in Extremely slow performance since upgrade:
@RasheedHolland said in Extremely slow performance since upgrade:
Flawed reasoning? You have to be kidding me. What I'm trying to explain is that this hasn't got anything to do with Vivaldi not being trusted after upgrade, HIPS are smart enough to alert you about this.
Not kidding you. Accurate observation and the accuracy of reasoning are my profession. Troubleshooting requires data, data requires observation, and observation requires experimentation. It is impossible to troubleshoot by argumentation, "logic," or winning arguments.
And about the discussion about how likely it is that HIPS might interfere with new browser versions. You should also look at the technical aspects like: Is this HIPS injecting code into the browser? Does the browser have the right permissions? Do we see this HIPS blocking certain behaviors in the log file? Has this HIPS caused problems in older versions of Vivaldi, or other browsers like Edge, Opera and Firefox? These are all important things to consider, when pointing your finger towards HIPS as the possible problem. That's all I'm saying.
-
@RasheedHolland said in Extremely slow performance since upgrade:
Or is it perhaps a better idea, if developers gave an option to disable this Portals feature, which was a major design change in Vivaldi 6.2? This would perhaps save us a whole lot of time.
This is a discussion about troubleshooting a browser issue, not a legal trial. It's not about finding "guilt" (eg: SS vs. Vivaldi), it's about finding specific, contributory factors leading to the problem you are seeing. Developers and helpers here don't have access to your system. They are (and consistently have been) asking you to eliminate potential factors that make your system unique from theirs, one-at-a-time, to see what (if anything) seems to clear the problem on your system. 'Elimination' may include 'removal', since hooks into code are likely causes of perturbations of that code: they affect the code's interactions, timings, and other processes, even when "disabled". With that 'elimination' information, others may gain clues about what are the specific interactions that are triggering the issue on your system - and they are interactions which are not commonly being observed on most other systems. That same factor-isolation technique should apply to anyone else experiencing this problem.
Your "solution" of developers simply reversing the Portals feature code is you tossing darts at a board to see what sticks, even though the great majority of users with those same versions are neither seeing nor reporting the problem. Portals may not even be a contributory cause of the issue for those who do see it - if you look at the release notes, many other things besides Portals have changed since version 6.2, including chromium engine updates. It's a lot more reasonable, and "logical", to request users suffering the problem to practice elementary troubleshooting to help developers converge more quickly on the true problem cause and fix it if possible, yet you seem unwilling to try. If you are unwilling or unable to follow basic troubleshooting methods, I'm uncertain what you're here asking others to help with.
-
@Blackbird said in Extremely slow performance since upgrade:
@RasheedHolland said in Extremely slow performance since upgrade:
Or is it perhaps a better idea, if developers gave an option to disable this Portals feature, which was a major design change in Vivaldi 6.2? This would perhaps save us a whole lot of time.
This is a discussion about troubleshooting a browser issue, not a legal trial. It's not about finding "guilt" (eg: SS vs. Vivaldi), it's about finding specific, contributory factors leading to the problem you are seeing.
Exactly, and I have already performed a troubleshoot, and based on other people that posted in this thread, I came to the conclusion that it's most likely some problem (perhaps with memory management) in Vivaldi, not caused by some third party software conflict. We should not forget that not all people use Vivaldi in the same way. Some may use a lot of extensions, some may use a lot of tabs, and perhaps that's why not all people are seeing this. Of course you may disagree with this conclusion.
Your "solution" of developers simply reversing the Portals feature code is you tossing darts at a board to see what sticks, even though the great majority of users with those same versions are neither seeing nor reporting the problem. Portals may not even be a contributory cause of the issue for those who do see it - if you look at the release notes, many other things besides Portals have changed since version 6.2, including chromium engine updates.
Yes I know, it was only an idea, that developers could try. What if it does all of a sudden solves the problem? Then we could come to the conclusion that at least on certain systems it plays a role. And the Chromium engine changes all of the time, so I don't think that's a major factor, because it would most likely also affect Brave and Edge. But of course I'm just guessing.
It's a lot more reasonable, and "logical", to request users suffering the problem to practice elementary troubleshooting to help developers converge more quickly on the true problem cause and fix it if possible, yet you seem unwilling to try. If you are unwilling or unable to follow basic troubleshooting methods, I'm uncertain what you're here asking others to help with.
Where did you see me disagree with this? Of course people should troubleshoot, but it should be a logical troubleshoot. And you can not say we should perform all steps without reasoning, in my view. For example, this EricJH guy claims that it's necessary to uninstall all security tools. I have to disagree with this, I've performed malware testing in the past and I can tell you that when you disable for example SpyShelter it really stops monitoring process activity. Same goes for Windows Defender. In other words, it's a pointless step, in my view.
-
@kenzaii said in Extremely slow performance since upgrade:
Do you have any good advice for debugging/profiling things like these? The best ways to gather information/realtime data/reports? Like looking at serviceworkers-internals for example, since there must be more places where I can see what is going on. I'm interested since I'm a developer, so would appreciate some advice on debugging the browser, which you know has worked well. Thanks.
Hi,
For the moment you can use this.You can add the Crash Logs to the Official Reports, this is mentioned when reporting.
Crash Logs seems not easy to read, so you can leave it or try to dig into it.
Regarding Service-Workers, this is something you can safely clean regularly.
-
Have been having the same sort of problem as described, started around the version that introduced portals, browser slows over time, hangs in memory when restarting.
AMD CPU, Win 11, MS Defender.
Work with 3 or 4 windows and around 70 tabs.
Restarting solves the issue for a day or so.
Tried a new profile but has not improved things. -
After deleting a workspace my browser stopped responding. I guess it is because of windows efficiency mode that is impossible to turn off entirely, only for some processes and not for a long time (it turns on on its own after some time). That's why the required process does not do its thing or does it very slowly. I managed to revive my browser after turning this mode off in the task manager for some random process of vivaldi (there are 56 of them), I hate windows and wanna switch to linux, but I believe that not many people will do that, so this problem will keep on happening for the majority of users...
-
I thought I was on to something by disabling the tab cycler as this seemed to speed things up a bit. I have CTRL+Tab & CTRL+SHIFT+TAB assigned to buttons on my mouse and these actions exhibit the most notable slowdowns (regardless of mouse or keyboard). But alas, no... Vivaldi just wants to be slow.
Win11, liquid-cooled AMD 12C CPU, 64GB RAM, 1TB NVMe (OS), 4TB NVMe (data), RTX 3090 <-- it ain't a hardware problem, to whoever suggested that
-
12k views for this thread and no official communication (by the devs or staff member, I mean) from the Vivaldi team... great
-
@vivaldibecameSLOW Since it's a rare finding, and there is still absolutely no definitive indicator what might be causing it in these rare cases, what exactly did you expect devs or staff to say/do? (Especially given that, as a rule, they don't read here, and rely on actual bug filings to locate weaknesses in the code)
This forum is for users to help other users. And so far, not one single reporting user has actually completed all of the necessary troubleshooting steps for any other user to begin to try to help.
-
"""Rare finding""" lol, there are have been many reports of this bug now.
not one single reporting user has actually completed all of the necessary troubleshooting steps for any other user to begin to try to help.
What more do you want?
-
Well I give up, I'll just switch to Firefox. I've endured many bugs and the usual slowness of Vivaldi compared to other browsers, but this particular performance regression/bug makes Vivaldi unusable.
I've only upgraded my browser a few weeks ago (from an old version), but apparently this bug was introduced many months ago. I don't know how others put up with this bug for so long. -
Several, not "many" people have described a similar symptom. I say similar, because the reports are not all actually the same.
Aside from these people, literally millions do not have similar symptoms.
And literally no one has actually completed troubleshooting that narrowed down the symptoms to any cause or area, shared by more than one person, on which anyone could put their finger. So devs, who don't have slowdowns, don't have testing to rely on. Testers, who likewise can't produce any slowdowns, have not been able to provide guidance that the devs can rely on to narrow down a cause they can fix. Users, several of whom claim similar symptoms, have not reported any commonality that devs could hang their hats on. Yet somehow, magically, devs are supposed to be able to suss out where, in millions of lines of code, the fault for a general report of "slowdown" lies.
In each and every case, something is happening. But what is it? Why does it happen at your end, while I cannot produce it on any of 3 Vivaldi versions on six machines from 3 to 10 years old running six different kinds of processor architecture and four different kinds of RAM, 6 different GPUs, four different kinds of displays, on Win10, Win11 and ArchLinux? There is one thing in common between my testbeds. I run no extensions and have no 3rd party security running on any of them.
But while no user has actually completed troubleshooting, and no two users have reported an environmental commonality, it is negligence or malice on the part of Vivaldi and its volunteers that is behind the failure, so far, to fix a generally similar user complaint. It would be great if we had actionable data to work from. So far, we don't.
-
Several, not "many" people have described a similar symptom.
Many, not "several". There's 9 upvotes on this topic, and people have reported similar problems in this topic, others topics in this forum, and also on Reddit (maybe elsewhere too).
And literally no one has actually completed troubleshooting that narrowed down the symptoms to any cause or area
Lol if we could narrow down the problem, wouldn't that be great?!?
Yet somehow, magically, devs are supposed to be able to suss out where, in millions of lines of code
Ignorant phrasing. "Millions of lines of code" is irrelevant. The bug was introduced in an incremental version i.e. you don't have to inspect MILLIONS OF LINE OF CODE, but "just" the lines of code modified/created in the new version. This is not the very first version of Vivaldi, where MILLIONS OF LINE OF CODE would have been relevant.
Why does it happen at your end, while I cannot produce it on any of 3 Vivaldi versions on six machines
Try this: have a very large history (250,000/300,000+ links), open Vivaldi and use it for many hours/days WITHOUT closing Vivaldi. The slowness appears after one/a few hours but become more and more noticeable over time. Don't shutdown your computer, use "hibernate" instead and over the next days, Vivaldi progressively becomes extremely slow.
Another problem with a big history is that if you ever open the history tab, it slows down the browser instantly, and remains in this state of extreme slowness even if you close the history tab. There is always some high CPU usage.
And before you tell me to delete my history: 1) I don't want to, it's one of Vivaldi's best feature 2) it worked before, and was broken by an update.
This has been the case since August 2023 apparently: https://www.reddit.com/r/vivaldibrowser/comments/16y25cf/fixed_macos_menus_direct_match_vivaldi_browser/k3gxafj/
-
What version of Vivaldi do you run?
How many tabs do you run on average?
Do you run any extensions?
Have you installed any modifications to Vivaldi?
Do you game?
Do you play any background media?
I never shut Vivaldi down except to update. On this machine that's every day or two. This machine stays running for weeks on end. It does not hibernate, only nap. At present, I only keep a week of history. (I have a month of history in my Stable instance) To get a large history, I will have to change the setting to "forever" and run it for a long time. But if your browser slows down in a matter of hours, I'm not sure how that will help. Mine does not slow down in a matter of weeks.
For Vivaldi 6.2, the browser was changed to portals configuration, which took over two and a half years for multiple devs to write. Millions of lines of code. It was not incremental in its implementation. It was all at once. It was tested incrementally by us volunteer guinea pigs (Sopranos) but of course at no point did "slowdown" become an issue - or it would have been fixed at the time. Further, every change in code affects portions of code the programmer didn't touch. Guessing is not a viable strategy. Neither is reverting two and a half years of work that benefitted millions, and some few are complaining about - especially if the fault is not actually in the code itself, but rather some environmental factor(s).
"It was broken by an update" is a faulty assumption. "It was broken by some reaction between (this) machine's setup and an update." is actually more likely. Keep in mind - something broke there. Nothing broke here - nor on many other machines whose users doubtless mimic your browsing habits.
-
@vivaldibecameSLOW Incidentally - did you intend to post a link to a MacOS problem?
-
@magilex said in Extremely slow performance since upgrade:
Have been having the same sort of problem as described, started around the version that introduced portals, browser slows over time, hangs in memory when restarting.
AMD CPU, Win 11, MS Defender.
Work with 3 or 4 windows and around 70 tabs.
Restarting solves the issue for a day or so.
Tried a new profile but has not improved things.Yes, it's the same as others have reported. Some still believe it must be individual problems that we must be having on our machines, but I'm seeing a clear pattern.
-
@pfine said in Extremely slow performance since upgrade:
I thought I was on to something by disabling the tab cycler as this seemed to speed things up a bit. I have CTRL+Tab & CTRL+SHIFT+TAB assigned to buttons on my mouse and these actions exhibit the most notable slowdowns (regardless of mouse or keyboard). But alas, no... Vivaldi just wants to be slow.
Win11, liquid-cooled AMD 12C CPU, 64GB RAM, 1TB NVMe (OS), 4TB NVMe (data), RTX 3090 <-- it ain't a hardware problem, to whoever suggested that
I totally forget about you, who actually started this topic, cool to see that you haven't given up on Vivaldi. I remember that you had actually made the switch to Edge, who knows how many people may have switched already because of this problem.
