6.2 - 6.6 | Slow auto-complete History suggestions
-
@mib2berlin @BenziJunior No, I am still using Firefox as secondary browser. I imported Opera's history into Vivaldi and I just have ~10 months of history on Vivaldi right now. I never realized Opera had not been keeping all of my history like Firefox does, until I moved to Vivaldi and imported my Opera history.
I originally had some issues with Vivaldi refusing to show my history past a specific date, but it seems to be working fine right now. The auto-complete slowness, however, started immediately after a Vivaldi update for me, just like everyone else.
-
Thank you very much for your work on this issue! This has been by far my biggest gripe with Vivaldi, one that has been getting worse as my history gets larger. I was very happy to see that things are much improved in the latest snapshot.
Could you please apply the same fix to the searches on
vivaldi://history/
? I see that you are specifically working on urlField performance, but the issue onvivaldi://history/
is fully identical to the one @Mercury048 described, with every keystroke being searched to completion. For example, if I pastevivaldi
to the search field of the history page, the search takes 10 seconds, but if I typevivaldi
directly to the search field, it takes 80 seconds!For reference, my history file is 450MiB, with 6 years of history.
10 seconds for search is of course terrible too, but it is lightning fast compared to 80 seconds, so over the last few years I've been using workarounds to circumvent the issue @Mercury048 described and make searches in 10 seconds. e.g. I first type the search query somewhere else, and then cut and paste it to the history search field; or I switch the history to the day view, then type the search term (which searches quickly since it searches only today), then switch back to the list view with the whole history.
One day I hope that the inefficiency of the history page can be fixed as well, so that searches are near instant instead of 10 seconds. But that is a separate issue. I will be happy if you could apply this fix so that I can make searches in 10 seconds instead of 80!
By the way, I also face the other history regression introduced by 6.5 (presumably because of the full history sync feature) where the
vivaldi://history/
page takes 10-15 minutes to load, but that is less urgent of an issue for me because it happens only the first time after I started Vivaldi; afterwards, the history pages opens relatively quickly like before. Still very annoying, of course. -
@debiedowner
Interesting, looking into the history page is on my ToDo list, I'm still working hard on the URLField and unfortunetly the same techniques may not always be applicable.
However, if it has the same characteristics i.e. search requests being queued up it is very likely we can solve that in a similar manner.
Full disclosure, that particular issue was solved by my collegue my part was getting individual searches faster, but I'll point this issue out to him.
It'll be lower priority so don't hold your breath, but if it's the same problem then I wouldn't be surprised to see it before the next release. -
A new snapshot was released today, and I'm keen to get feedback on the changes we made.
https://vivaldi.com/blog/desktop/minor-update-four-6-6/
We changed tact from the previous snapshot that should result in a smoother input and smaller memory footprint.
(Not to mention circumventing a bug I accidentally introduced in the previous version) -
@BenziJunior said in 6.2 - 6.6 | Slow auto-complete History suggestions:
A new snapshot was released today,
You mean a Stable update!
Still waiting for Snapshot -
I am so glad that I stumbled across this post. I had been experiencing this issue for the longest time, and like many others have said, disabling the "search history" in the address bar essentially eliminated all problems.
And in my case, it's becaus I can out-type the address bar's thinking and completion. For example, I can type out "monkeytype" and the address bar would not be able to keep up with the typing, and if I immediately press enter before it catches up, I will end up searching Google.
Same thing, if I type in an address, and then want to select an option from the dropdown, I need to wait for the address bar to catch up and realize that I am done, before I can select. Otherwise, my inputs on the arrow keys are meaningless.
This leads to a delayed and slower searching experience, as I have to wait for the address bar to catch up and see if there are any changes that need to be made.
-
Please make Vivaldi fast again on all platforms. It has regressed to being unusable lately (last year or so).
-
@gorg You need to troubleshoot your Vivaldi. It is fast on all my platforms and all my machines (Win 10, Win 11, Android, Linux Mint, Machines from a year old to nine years old
-
@n810
Hi, I investigate at moment if a user set the privacy setting Save Browser History to a shorter time than Forever Vivaldi keep the history.
In version 6.5 changing the setting delete the complete history but now if I set from Forever to 3 month it keep the history of the 3 month.
I ask in the developer chat if this is a new "feature".
The Vivaldi team work on the "fastest typing on the planet" issue at moment.Cheers, mib
-
@mib2berlin I know that you can delete older search history, but that's besides the point. There is no reason why a browser should have a delayed search in filling in the address.
I know that that's the solution, but I would like to keep my search history longer than 3 months. And this did not used to be a problem a couple major versions ago. So it used to work properly.
Thanks!
-
@n810
I thought more about from forever to one Year.
In my opinion it was a big mistake to add a setting for forever, who need ten thousands of vivali.net entries from 10 Years ago.
I guess issues happen since the team completely rewrite the address bar code.
Now they try to fix this and they will do it.Cheers, mib
-
@mib2berlin said in 6.2 - 6.6 | Slow auto-complete History suggestions:
In my opinion it was a big mistake to add a setting for forever, who need ten thousands of vivali.net entries from 10 Years ago.
I do not, six months here.
But interesting idea, maybe keep only the last visit to an URL to reduce size and omit duplicates?
This would kill the real history of visits, but would keep all distinctive URLs over time. Needs to be a switch, as it is no true history, just a collection of URLs.
Well I would not vote for that, as I think it would not make my browsing experience better. -
@Ayespy
How large is your browsing history ? -
@bariton
Hi, I thought that was a bit exaggerated but I checked a system with 6 month setting and it has 28000 entries for forum.vivaldi.net.
Compared with one bookmark this is a huge waist of stored data.
I cant imagine how many it were if I set history forever surfing the forum for 9 Years now.
Completely useless.
May you check how many entries your most visited page has?
On the other hand, a database can handle millions of entries in milliseconds, Vivaldi should handle this much better as it does today.Cheers, mib
-
@all
Can anybody test what else is running if you start Vivaldi and/or type in the address bar?
Lately I notice open 30 tabs from a bookmark folder the Windows Defender takes 30% of my AMD Ryzen 7, 6 core CPU.
I immediately remove vivaldi.exe from Defender and it seems 30 tabs open faster now.
But I can't measure it exactly.
Maybe this is involved in the history issues, too.Cheers, mib
-
@mib2berlin
Hi, for 6 months and forum.vivaldi.net it shows 12k entries.
But I think it is not right to use the domain to count entries. The history is here to find a page you once visited and you have to remember a part of the title or URL to use it.
Yes, I am sure the database is fast enough. According to the forum, the address bar auto complete problem is about multiple searches running in parallel when typing, and a developer is working on it.But sorry, I did not really want to discuss that, as here is zero problems with the history, it was just a thought about avoiding duplicates of titles/URLs to reduce the DB size.
-
The same history I have on MacOS, so waiting for a fix.
-
@TbGbe said in 6.2 - 6.6 | Slow auto-complete History suggestions:
@BenziJunior said in 6.2 - 6.6 | Slow auto-complete History suggestions:
A new snapshot was released today,
You mean a Stable update!
Still waiting for SnapshotOh right my bad I was rather hasty and didn't read our own press release right.
I was just really keen to get feedback on the changes we are making, there are a lot of moving parts in this project.@bariton said in 6.2 - 6.6 | Slow auto-complete History suggestions:
@mib2berlin
Hi, for 6 months and forum.vivaldi.net it shows 12k entries.
But I think it is not right to use the domain to count entries. The history is here to find a page you once visited and you have to remember a part of the title or URL to use it.
Yes, I am sure the database is fast enough. According to the forum, the address bar auto complete problem is about multiple searches running in parallel when typing, and a developer is working on it.But sorry, I did not really want to discuss that, as here is zero problems with the history, it was just a thought about avoiding duplicates of titles/URLs to reduce the DB size.
We have the multiple queries queueing up already fixed and that is coming in the next release, we still have problems with individual searches being to slow, although significant progress in that area.
Sadly I was unable to get my work ready in time to make it into the our upcoming release, they should be in the first snapshot after that and barring some catastrophic regression being found when being found in testing, it should be coming in the next release after this one.
-
After finally upgrading to 6.7, I can confirm autocomplete searches are back to what they should be.
Thank you to the devs who made the fix.
And a very petty "I told you so!" to the commenters who insisted there's no way to expect a years-long browser history to perform well. (You know who you are.)
-
@BenziJunior said in 6.2 - 6.6 | Slow auto-complete History suggestions:
I'm unable to reproduce the issue with my test DB, as I'm seeing the history page load in seconds. I have some ideas as to what could be happening and will get back to you with some further questions and suggestions.
Is there any solution to fix the problem?
In version 6.7 the problem persists.