-
Notifications
You must be signed in to change notification settings - Fork 112
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Two issues I deal with a lot on tablets + one requested addition #39
Comments
egervari
changed the title
Two issues I deal with a lot on tablets
Two issues I deal with a lot on tablets + one requested addition
Apr 15, 2016
All good ideas. I'll work on implementation as soon as I have time. |
cfinke
added a commit
that referenced
this issue
Apr 20, 2016
This change achieves a 35% decrease in memory usage for the demo I use to check things like that. See #39.
see #45 for async version |
I would be interested in a way to access the stem(s) as well. This would be very useful for client-side search, e.g. with lunr |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Typo crashes the application on an iPad whenever you use Typo.js to get suggestions. It sometimes works the first time, but iOS will close the application if you spike memory usage - such as loading the dictionary and doing suggestion searches. I think this really needs to be optimized.
As a temporary work-around, I went through the entire .dic file and removed all of the words that my application doesn't care about, getting the .dic file down to 37k.
For example, if you know that a word has no rules, then dictionaryTable does not need to contain so many empty arrays, or arrays that contain empty arrays. These objects take up memory. Just null everything out. The biggest culprits seem to be the generated words based on the rules in the dictionaryTable. This one modification alone would dramatically reduce memory footprint.
Also, the API needs to be changed so that it's asynchronous and uses promises by default. For the longest time, I had no idea it could be asynchronous and so it was blocking the UI. Upgrading to promises though is just going to be more and more mandatory for libraries. Modern apps in Angular or whatever are all promise-based now, as is most browser databases. So it's actually a bit awkward to see a defaulted synchronous library. I think at this point in time, the people who want to be synchronous should have to jump through hoops, instead of the other way around.
A nice function to have would be stems() that simply accepts a word and returns all of the replacement words for the rules associated with it. For example, if you pass in 'vibrate', it returns something like ["vibrations", "vibration", "vibrating", "vibrates", "vibrated"]. This is very useful for building full text searches. Since you already have the rules and the dictionary, why not make this function public? I see most of the code buried in _parseDIC, but it could be refactored out as a prototype method.
The text was updated successfully, but these errors were encountered: