z1dev / zkanji

Japanese language study suite and dictionary
GNU General Public License v3.0
61 stars 10 forks source link

Feature Request: improving "Translate From Japanese" responsiveness #38

Open MarcusAseth opened 3 years ago

MarcusAseth commented 3 years ago

EDIT: ignore this first message, I first thought this was a bug but then understood it is not, so I've changed the title of the topic to a Feature Request - detailed on the second reply to this topic :)

This seems very odd - if I search for う (90k entries) on "Browse Dictionary" it will bring up the results in a matter of milliseconds, if I do the same on "Translate From Japanese" the program will hang for about 1 second, which doesn't seems much but is very noticeable. Giving that (I would assume) they are both doing the same thing and bringing up the same amount of results, there must be something wrong with the "Translate From Japanese" search. I made a video in which I type and delete う in both as fast as I can, to better show the difference in responsiveness between the two:

https://user-images.githubusercontent.com/29839218/113098706-21823e00-91f9-11eb-8a22-c1c65495010d.mp4

MarcusAseth commented 3 years ago

Err... nevermind, I've just realized that "Browse Dictionary" has the dictionary already loaded all the time, and it just jump to the searched entry, so is not the same thing at all.

I'll change the title of the topic and the issue then to a Feature Request ^_^'

Would be feasable to make the search inside "Translate From Japanese" respond faster, or is something that would require changing too much? I have noticed that if you type "うk" in it it hangs immediately at the k pretty much the same ammount of time it hanged at the う, as if it is going again through the 90k entries found before to isolate all starting with "uk" sound - if that's the case, would be possible to make it build only once the lists of pointers to all the resoults for the many 2 sounds combinations like "uk","ae","it" etc... during the dictionary import, to speed up the beginning of a search? Past 2 letters wouldn't be needed because that would narrow it down to 10k results at most I think, so few that it would continue the search extremely fast with the current search method Or is that a bad idea? (or maybe too deep of a change) ?

z1dev commented 3 years ago

Searching for end-of-word う is indeed way slower than forward search for some reason. I might investigate this on the weekend.

Sadly there is a general performance issue too, which is mainly due to Qt. Even if you just click on a line, it will take a second sometimes to react, and scrolling through all results is slow at first. That part is due to the way the free font library Qt uses manages drawing. It's not pre-caching fonts, and gets very slow with Japanese characters (and there are many of those.) I did performance tests several times after I rewrote the dictionary, but it always ended up pointing at Qt as the culprit. What's worse, this used to be faster on Windows 7 and not this bad on Windows 10, but with updates, it seems to have slowed down even further... But enough ranting from me 😄

MarcusAseth commented 3 years ago

I hadn't even realized I had the "end of word" search active! That's a good thing to notice, I can work around it for now by turning it off unless I really need it :)

z1dev commented 3 years ago

Side note if you haven't seen yet, I opened the Discussions page here for non-bug related stuff! It shows me as subscribed, so hopefully I'll get notifications of that one, even if GitHub fails to do that regarding bug reports...