WIP: Non-blocking filtering

[chendo]

This PR moves the fuzzy matching off the main thread for much improved responsiveness. It also only executes the fuzzy matching after 50ms of no typing activity to decrease the number of searches significantly which should save battery life.

I haven't used it enough to make sure it's stable, would like to have people help me test this particular branch.

• Add ability to configure delay

[chendo]

Whoops, found a critical crash. Don't use yet

[chendo]

Fixed

[slazyk]

Cool! Did you try to measure somehow the increase in responsiveness to see what helps? Does moving into background queue actually help? Or is it solely the effect of adding the delay? I am worried that not everything we are using is safe to use from another thread than one calling setFilteringPrefix:...

Since it is a sensible thing to do, it might be the case that Xcode already calls setFilteringPrefix: with some sort of delay mechanism to prevent multiple calls when typing fast. Maybe it simply is shorter and we can override delay there and make it configurable?

Why store _fa_forceFilter instead of passing it as an argument to _fa_kickFilterTimer and then to _fa_performFuzzyFiltering? Not that we actually use it, but seems more error prone to store it.

Why NSOperationQueue over GCD? I don't see much cancellation logic within the methods (besides the check just before setting the results). Maybe simply using a serial gcd queue would be good enough?

I think the suspicious nil you were seeing would be the case in which DVTTextCompletionSession was finished and was retained only by the async block. We might try to detect this case somehow and break earlier.

[mokagio]

Hey guys! I've been using this branch all morning and seems to run pretty well.

Although I just noticed this, if I type each letter of something that pops up in the autocompletion this happens:

So, say I want to type all the characters in NSString

type: N screen: N
type: S screen: NS
type: S screen: NSS
type: t screen: NSSt
type: r screen: NSStr
type: i screen: NSStri
type: n screen: NSStrin
type: g screen: NSStrin      nothing happens
type: 1 screen: NSString
type: 2 screen: NSString1
type: 3 screen: NSString21
...

[chendo]

@slazyk:

No hard measuring, purely subjective, but given that filtering takes 100-200ms for me, having it no longer block the main thread makes it significantly more usable. From what I can see, Xcode doesn't call it with a delay because prefix-only matching is fast enough to not warrant the extra complexity.

Good point on storing forceFilter, I'll change it. Wanted to make sure there was no major stability issues first before focusing on cleanup.

I picked NSOperationQueue to make it easy to purge all existing operations when queuing another one. I'd have to add more stuff to do that with pure GCD.

[chendo]

@mokagio that's crazy! I can't seem to reproduce that locally at this stage though. Does it happen 100% of the time for you?

[mokagio]

@chendo yes, 100% of the times I type all the characters. There's more, this is what happens when typing NSDecimalNumber

I built the project from 21b879a, and I'm using Xcode 6.1.1 (6A2008a)

---

Regarding the speed, it feels smother to me too 😃 But would be interesting to see how much it actually is.

[chendo]

@mokagio what settings are you using? I'm on the same build of Xcode and tried changing a few settings but still can't seem to reproduce

[mokagio]

@chendo I'm using the defaults settings. What other information can I give you?

Before building the feature branch I removed the plug-in via Alcatraz, restarted Xcode, then built the project.

[chendo]

@mokagio if you could screenshot me each settings page that'll be tops. Also can you confirm it's that branch by going back to the alcatraz package?

[mokagio]

Yep it seems to be the branch. I just reverted back to the Alcatraz version (2.1.0), and it behaves as usual.

[chendo]

Copied settings exactly and now I can reproduce

[chendo]

You can avoid the problem by disabling inline preview for the time being. Personally, I prefer it have it turned off to easier see what I'm typing

[mokagio]

Ok, glad that you can reproduce, first step to fix it 👍 😃

[ethereal-engineer]

Hard to reproduce because who actually types ALL the characters? 😆

[mokagio]

@iosengineer lol that's true, it's the whole point of the plugin right? 😛

I found it out when writing a variable named description that clashed with a snippet I have that's triggered by desc.

[tonyarnold]

@chendo merrrgggeee thissssssss

[chendo]

I haven't been able to revisit this recently but the plugin hasn't crashed for me in the last couple of weeks.

@slazyk good point regarding the forceFilter variable, I'll remove it when I have the time. Any other issues?

[slazyk]

I haven't tested much, but was able to reproduce what @mokagio reported, and also remember seeing wrong results in some cases, let me investigate a little.

BTW I should have some spare time soon, I can try finishing this up if you don't have the time.

[chendo]

Personally, I think showing inline preview makes correcting a typo harder so I have it off, which is why I didn't notice while developing. Are there stats on how many people have the option turned on?

Cool, that's fine by me.

[OdNairy]

Any updates about non-blocking filtering?

[chendo]

Superseded by #102