Benchmark: js search - MeasureThat.net

HTML Preparation code:

<script src="https://unpkg.com/lunr/lunr.js"></script>
<script type="text/javascript" src="https://rawgit.com/bvaughn/js-search/1.2.0/dist/js-search.js"></script>
<script type="text/javascript" src="https://cdn.jsdelivr.net/npm/minisearch@2.2.2/dist/umd/index.min.js"></script>
<script>

        Benchmark.prototype.setup = function() {

          
  var books = [];
  var xmlhttp = new XMLHttpRequest();
  xmlhttp.onreadystatechange = function() {
    if (xmlhttp.readyState == 4 && xmlhttp.status == 200) {
      var json = JSON.parse(xmlhttp.responseText);
  
      books = json.books;
    }
  }
  xmlhttp.open('GET', 'http://bvaughn.github.io/js-search/books.json', true);
  xmlhttp.send();

        
  };


      
</script>

Tests:

Lunr
var idx = lunr(function () { this.ref('isbn'); this.field('title'); this.field('author'); books.forEach(function (doc) { this.add(doc) }, this); })
js search
var search = new JsSearch.Search('isbn'); search.searchIndex = new JsSearch.TfIdfSearchIndex('isbn'); search.addIndex('title'); search.addIndex('author'); search.addDocuments(books);
minisearch
var miniSearch = new MiniSearch({ fields: ['isbn', 'title', 'author'], // fields to index for full-text search }); miniSearch.addAll(books)

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
Lunr
js search
minisearch

Fastest: N/A

Slowest: N/A

Latest run results:

Run details: (Test run date: 10 hours ago)

User agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36

Browser/OS: Chrome 131 on Windows

View result in a separate tab

Test name	Executions per second
Lunr	2600294.2 Ops/sec
js search	22075126.0 Ops/sec
minisearch	1373556.4 Ops/sec

Autogenerated LLM Summary (model llama3.2:3b, generated one month ago):

LLMs can make mistakes. Check important info.

Measuring the performance of JavaScript search libraries can be complex, but I'll break it down for you.

The provided JSON represents three benchmark test cases:

1. **Lunr**: This test case uses the Lunr library to create an index and add documents (books) to it. The `lunr` function is defined with three fields: ISBN, title, and author.
2. **js search**: This test case uses a custom JavaScript search library (not an official one) called "js search" to create a search index and add documents (books) to it. It defines two search indexes: one for the ISBN field using TF-IDF and another for the title and author fields.
3. **minisearch**: This test case uses the Minisearch library to create an index and add documents (books) to it. The `MiniSearch` constructor is configured with three fields: ISBN, title, and author.

Let's discuss each approach:

**Lunr**

Pros:

* Easy to use: Lunr provides a simple API for creating indexes and adding documents.
* Fast indexing: Lunr uses a disk-based indexing algorithm, which can be faster than in-memory algorithms used by some other libraries.
* Strong support for advanced search features like faceting and filtering.

Cons:

* Limited customization: While Lunr is flexible, it has limited options for customizing the indexing and searching process.
* Not as lightweight as other options

**js search**

Pros:

* Highly customizable: The custom JavaScript search library allows developers to tailor the search experience to their specific needs.
* Lightweight: As a custom library, js search can be more optimized for performance than some other libraries.

Cons:

* Steeper learning curve: Developing and maintaining a custom library requires programming expertise and time.
* Less support for advanced features: While js search provides basic search functionality, it may lack the advanced features offered by other libraries like Lunr or Minisearch.

**Minisearch**

Pros:

* Lightweight: Minisearch is a compact library that's easy to integrate into applications.
* Fast indexing: Like Lunr, Minisearch uses a disk-based indexing algorithm for fast performance.
* Simple API: The `MiniSearch` constructor provides an easy-to-use interface for creating indexes and adding documents.

Cons:

* Limited customization: While Minisearch is flexible, it has fewer options for customizing the indexing and searching process compared to Lunr or js search.
* Not as widely supported as other libraries

Other alternatives to consider:

* **Sphinx**: An open-source search engine library that's highly customizable but can be resource-intensive.
* **OpenSearch**: A cloud-native search engine that offers a range of features, including faceting and filtering, but may require more setup and configuration.
* **Algolia**: A commercial search-as-a-service platform that provides robust indexing and searching capabilities but requires subscription and has limitations on customization.

When testing these libraries, it's essential to consider factors like performance, ease of use, and customizability to determine which one best suits your project's needs.

Related benchmarks:

js search (version: 0)

Comparing performance of: Lunr vs js search vs minisearch

Created: 4 years ago by: Guest

Jump to the latest result

Lunr

js search

minisearch

Suite status: <idle, ready to run>

Experimental features:

Fastest: N/A

Slowest: N/A

Autogenerated LLM Summary (model llama3.2:3b, generated one month ago):