Several improvements to the internals of _search(_:in:) to avoid the less efficient parts of Swift's String implementation, namely the fact that count is O(n) for a string of length n, and String.index(_, offsetBy: n) is also O(n).

Overall speedup of up to 2.5x for search operations.

FuseUtilities.swift:

• add a version of calculateScore which takes a patternLength parameter, to avoid repeated calls to String.count, which is O(n) for a string of length n.
• calculatePatternAlphabet: eliminate unnecessary loop zeroing mask by using nil coalescing instead.
• calculatePatternAlphabet: eliminate unnecessary calls to String.index(_, offsetBy: n), which is O(n), by instead looping through pattern.enumerated().
• findRanges: eliminate unnecessary variable end and unnecessary subtraction of one, using ..< instead of ... operator.

Fuse.swift:

• change all calls to calculateScore to use pattern.len (see FuseUtilities.swift)
• calculate text.count only once
• eliminate unnecessary Double/Int conversions in calculation of binMid
• avoid calls to text.char(at:), which is O(n+j) for offset of j in string length n, instead calculate index of currentLocation once, then apply String.index(before:) once per loop iteration, which is O(1).

String+Fuse.swift:

• avoid deprecated encodedOffset and instead compare self.count to position

Hi,

Is there any reason why the below line of string comparison would lead to a crash?

    let result = fuse.search("Rancheras 2016 Borracho de Amor  Por Tu Maldito Amor  Hermoso Carino  Se Va Muriendo Mi Alma  Por un Amor", in: "Borracho De Amor")

Any help would be appreciated. Thanks!

Hi,

it seems that Example 3 with search in Fusable is not working? The results is always empty? I tried installing from github both the latest version and from "c7adb16" as mentioned in issue 40, but still there is no printout happening.

This removes the point of coordination introduced in a9c2f5b9893bd52e01c1d7bc5636f8bd2e77a2e0 when making the APIs thread-safe, by changing the updates to the result array from sync to async.

This enables Fuse to safely access optional properties that might be nil.

Also upgrades to Swift 5.0 & bumps version in Podspec but I can exclude that change if necessary for some reason.

Hey, thanks for this lovely library!

I noticed an issue where the score would equal 0 no matter the weights when having a perfect match on a property. Looking into Fusejs I found that they fallback to 0.001 when this is the case to account that issue. This PR adds the exact same fallback.

I haven't looked into what different approaches your library uses to calculate the score compared to FuseJS so I'm not really sure whether the fallback number should be any different or not?

Added fixes for issues that caused quite frequent crashes in our app.

Removed forced position unwrapping. Added check whether startIndex offset by position is still between bounds (less than endIndex). Added check for ... range iteration so that start is less than finish.

This should be considered after Pull #3.

Goal

1. Simplify attributed string generation for displaying filtered results by using system provided functions.
2. Use NSAttributedString instead of NSMutableAttributedString in contexts where attributed strings are not mutated.

When using the returned CountableRange<Int> values to create attributed strings, highlights come a char short. For example:

let options = ["active", "inactive", "canceled"]
let query = "act"
let results = fuse.search(query, in: options)

Results: (0, [0..<2]) & (1, [2..<4]) Expected results: (0, [0...2]) & (1, [2...4])

In my understanding search should be returning CountableClosedRanges, instead of half-closed CountbleRanges.

The example project would have the same issue, if it were not for the <= comparison in offset <= range.endIndex. This essentially treats the half-closed range as a closed range.

The maintainer hasn't responded to neither PRs nor Issues for more than six months.

Yet the project is still asking for donations https://patreon.com/fusejs https://www.paypal.com/paypalme2/kirorisk

We need to know if this repo is going to be maintained so that we know whether it's worth sponsoring this project or if we should fork it and continue ourselves.

If I repeatedly search over similar datasets with the same parameters, I wonder if I should use the same Fuse object for all searches:

let fuse = Fuse()

func search() {
  return fuse.search...
}

vs. using a new Fuse object for every search

func search() {
  return Fuse().search...
}

Of particular concern to me is that I am using the async APIs which rely on per-instance dispatch queues. I kind of like the idea of using a new Fuse object for every search so that the searches don't "compete" on the same dispatch queue, but I don't know if there's actually any limit to concurrency per-custom-queue (as opposed to at the level of the global queues that back these custom queues, or eventually at the level where the work items are scheduled on threads, in which case different Fuse objects would be competing anyway).

I also don't know if there's overhead to having many custom dispatch queues, in which case it would be better to reuse one Fuse object. This Stack Overflow makes it seem like this wouldn't be a problem.

Here is my implementation. it always succeeds while checking if !item.responds(to: Selector(property.name))

extension Member: Fuseable { var properties: [FuseProperty] { return [ FuseProperty(name: name ?? ""), FuseProperty(name: phone ?? "") ] } }

func searchBar(_ searchBar: UISearchBar, textDidChange searchText: String) { guard searchText.count > 0 else { self.displayedMembers = self.allMembers self.membersTableView.reloadData() return } self.displayedMembers = searchEngine.search(searchText, in: self.allMembers).map { self.allMembers[$0.index] } self.membersTableView.reloadData() }

In this operation, Fuse is given a pattern

pattern = neighbours

And a string

content = Mr and Mrs Dursley, of number four, Privet Drive, were proud to say that they were perfectly normal, thank you very much. They were the last people you’d expect to be involved in anything strange or mysterious, because they just didn’t hold with such nonsense. Mr Dursley was the director of a firm called Grunnings, which made drills. He was a big, beefy man with hardly any neck, although he did have a very large moustache. Mrs Dursley was thin and blonde and had nearly twice the usual amount of neck, which came in very useful as she spent so much of her time craning over garden fences, spying on the neighbours

However despite there being an exact match, the operation fails.

Fuse().search(pattern, in: content) //Produces nil

I'm using the blocking version of search, and would like to continue to do so if possible.

Appreciate any help, thanks!