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

Allowing to load data without serializing to JSON first. #115

Open
kkirby opened this issue Nov 12, 2014 · 4 comments
Open

Allowing to load data without serializing to JSON first. #115

kkirby opened this issue Nov 12, 2014 · 4 comments

Comments

@kkirby
Copy link

kkirby commented Nov 12, 2014

Hello.

I'm storing data using IndexedDB, which does not need to be serialized to JSON first. However, Lunr relies heavily on the automatic call of toJSON by JSON.stringify. Because of this, calling lunr.Index.load(index.toJSON) does not work as expected. This exact issue has come up previously (#52).

After review of the code, the only instance that needed to be updated was toJSON on lunr.Store.

This is my proposed code update:

lunr.Store.prototype.toJSON = function () {
  var store = {};
  for(var key in this.store){
    if(!this.store.hasOwnProperty(key))continue;
    if(typeof this.store[key].toJSON == 'function'){
        store[key] = this.store[key].toJSON();
    }
    else {
        store[key] = this.store[key];
    }
  }
  return {
    store: store,
    length: this.length
  }
}

I'll be making a pull request shortly.

kkirby added a commit to kkirby/lunr.js that referenced this issue Nov 12, 2014
Updated lunr.Store to call toJSON on lunr.SortedSet.
@olivernn
Copy link
Owner

Why is this better than just storing the stringified JSON output in IndexedDB? Just trying to understand the use case where this is a better solution.

@kkirby
Copy link
Author

kkirby commented Nov 17, 2014

Speed. Calling JSON.stringify is far slower than just storing the data as-is.

@olivernn
Copy link
Owner

Would you mind providing some benchmarks showing the difference in performance between this implementation and the current implementation?

Are you sure that the slowness comes from JSON.stringify, I have a feeling it might be more due to having to traverse all the objects which this implementation will still have to do, some benchmarks would give us an actual answer though. I'd also be interested in the performance difference in actually generating a JSON string with both implementations.

@kkirby
Copy link
Author

kkirby commented Nov 17, 2014

I went ahead and did a crude benchmark and I don't really know what to make of the results. In some aspects your code and using JSON.stringify is faster, but in some aspects it is not.

For reference, here is the fiddle: http://jsfiddle.net/0qvo6kuo/16/

The numbers will be stored in the console. If the word "json" appears, then the data was stringified/parsed. If the word "save" appears, then the data was saved/retrieved from the IndexedDB.

My issue with the numbers is that, even though my implementation is longer, it doesn't block the UI thread.

What if we introduced a new method that allowed for saving/restoring Lunr without JSON? That way we could keep the toJSON implementation, which is fast for JSON, and have another implementation that will just dump out the data.

Let me know your thoughts.

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

2 participants