Skip to content
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

Open
egervari opened this issue Apr 15, 2016 · 3 comments
Open

Two issues I deal with a lot on tablets + one requested addition #39

egervari opened this issue Apr 15, 2016 · 3 comments

Comments

@egervari
Copy link

egervari commented Apr 15, 2016

  1. 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.

  2. 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.

  3. 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.

@egervari 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
@cfinke
Copy link
Owner

cfinke commented Apr 18, 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.
@kofifus
Copy link

kofifus commented Sep 4, 2016

see #45 for async version

@groe
Copy link

groe commented Feb 2, 2018

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
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants