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

Search sluggishness #67

Closed
DavidEBest opened this issue Nov 10, 2015 · 9 comments
Closed

Search sluggishness #67

DavidEBest opened this issue Nov 10, 2015 · 9 comments

Comments

@DavidEBest
Copy link
Contributor

LotLinker has always had a noticable delay in accepting user input & returning search results. This is especially bad for IE, which displays the 'this page is not responding due to a long running script message'.

How can we improve the experience?
Ideally, we:

  • remain client-side only
  • improve general responsiveness
  • get rid of the 'long running script' warning on IE

Open to:

  • replacing our typeahead plugin
  • indexing more at app startup (including putting a loading/wait screen)
  • going to a server-based search (only if absolutely necessary)
  • any other clever ideas
bowmanmc added a commit to bowmanmc/daytonreap that referenced this issue Nov 11, 2015
The newer version of typeahead.js limits the number of results put into
the suggestions dropdown.
DavidEBest added a commit that referenced this issue Nov 12, 2015
Update to typeahead v0.11 to fix issue #67
@jlalthoff
Copy link

did this upgrade improve performance any? I don't have IE or any sluggishness to compare to.

I did find changing the minLength to 2 in $("#addressInput").typeahead({
reduced the milliseconds used for the first search by a factor of 10 .

@DavidEBest
Copy link
Contributor Author

It could be better, but that change did improve the results. I've experimented some with changing the input length. That is a good way to improve performance; we need to account for the properties re-appearing on the map when the field is cleared.

@itopaloglu83
Copy link
Contributor

After working with Jeff today, we have come to the realization that the site is perpetually searching after typing anything in the search field. I hypotise that this is because of the search index array "markerSearch" is dynamically updated.

@DavidEBest
Copy link
Contributor Author

Good find! 👍

@itopaloglu83
Copy link
Contributor

itopaloglu83 commented Feb 3, 2017

Well, we were wrong. I profiled the website.
Sluggishness comes from the setMarkers() function.

It is used to update the map according to the search result. However, when the user clicks on the search box, setMarkers takes 900ms to complete. After the initial character it takes another 400ms to complete. Following keystrokes takes less time due to diminishing results. And then, when there's no result found, setMarkers again sets all the markers and takes 900ms to complete.

@itopaloglu83
Copy link
Contributor

This is a issue related to leaflet dependencies. They resolved this issue (#357) with the current version. Could someone please update the following dependencies to their current versions?
"leaflet"
"leaflet.markercluster"
"Leaflet.awesome-markers"

@DavidEBest
Copy link
Contributor Author

Could you try this locally to confirm that it is the problem?

The bower.json file defines the versions of the libraries to include. If you update that file and then run bower install it should give you the most recent versions. The package search engine at bower.io should contain the version numbers of the most recent versions.

@itopaloglu83
Copy link
Contributor

I don't have my development environment setup yet. So, I had to improvise. I confirmed that the solution worked by manually replacing javascript references (leaflet, leaflet.markercluster and leaflet.awesome-markers) in the index.html.

@DavidEBest
Copy link
Contributor Author

Much better... good find with the leaflet dependencies. I've pushed the change to the live LotLinker site. 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants