Search Performance

[Mctalian]

While it's not hugely an issue, when we get up to 1000 ideas it does get a bit sluggish. Around 300 seems to work alright. I think it's mostly DOM rendering that is slowing it down. We can probably address this in a few ways (Phase 2 or 3, in my opinion) those being:

1. Web Workers (perhaps do the search filtering in its own worker so the DOM rendering can happen on its own thread and not have to wait for the filtering to be finished, though I'm not sure this will resolve our issues. Could be we just have too much for Angular to render.)
2. React.js (I've seen a lot of examples where React thrives with a lot of DOM elements. Would need to investigate more because I have not personally had any experience with React)

[Mctalian]

I did a few things to make minor improvements (No PR yet), but they are pretty negligible. Perhaps when @YashdalfTheGray has finished the backend, we'll see about server-side filtering and do some sort of benchmarking. It could even be just simple perception of speed and not actual data because the delay is noticeable now.

[LongArmMcGee]

It may be better to implement some metrics gathering to report what sort of
performance users are getting before we look at any implementing
performance improvements.
On Dec 22, 2015 1:18 PM, "Robert" [email protected] wrote:

I did a few things to make minor improvements (No PR yet), but they are
pretty negligible. Perhaps when @YashdalfTheGray
https://github.com/YashdalfTheGray has finished the backend, we'll see
about server-side filtering and do some sort of benchmarking. It could even
be just simple perception of speed and not actual data because the delay is
noticeable now.

—
Reply to this email directly or view it on GitHub
https://github.com/YashdalfTheGray/flintandsteel/issues/162#issuecomment-166695313
.

[YashdalfTheGray]

We could possibly go with web workers. I have looked into react and if we structure our DOM elements correctly (the easiest optimization being using track by $index with our ng-repeats, we can come pretty close to the react performance without needing to restructure our pages and pull in another dependency.

[YashdalfTheGray]

Also, I have created an endpoint for searching too. If you POST to /ideas/search, it will return a bunch of idea headers related to your search. Check out the searching section of server/data-access.md.

I kind of want to close this out since we have something for the time being and searching happens on the server side. Since we control both the API and the front end for now, we can change the search however we want to fit our needs too.

[Mctalian]

I tried track by, didn't help as much as I hoped
On Dec 30, 2015 1:43 AM, "Yash" [email protected] wrote:

Also, I have created an endpoint for searching too. If you POST to
/ideas/search, it will return a bunch of idea headers related to your
search. Check out the searching section
https://github.com/YashdalfTheGray/flintandsteel/blob/master-author/server/data-access.md#searching
of server/data-access.md.

—
Reply to this email directly or view it on GitHub
https://github.com/YashdalfTheGray/flintandsteel/issues/162#issuecomment-167946257
.

[Mctalian]

Hmm... why is this one closed?
On Jan 26, 2016 6:15 PM, "Yash Kulshrestha" [email protected]
wrote:

Closed #162 https://github.com/YashdalfTheGray/flintandsteel/issues/162.

—
Reply to this email directly or view it on GitHub
https://github.com/YashdalfTheGray/flintandsteel/issues/162#event-527269415
.

[YashdalfTheGray]

I figured that we've got a search endpoint now and we'll transition to using that. It should be a lot more performant and we can modify it as we see fit. This solves the front end search performance issue which is what this was referring to.

[Mctalian]

It doesn't solve anything because we're not using it yet. There's still
work to be done.
On Jan 26, 2016 6:25 PM, "Yash Kulshrestha" [email protected]
wrote:

I figured that we've got a search endpoint now and we'll transition to
using that. It should be a lot more performant and we can modify it as we
see fit. This solves the front end search performance issue which is what
this was referring to.

—
Reply to this email directly or view it on GitHub
https://github.com/YashdalfTheGray/flintandsteel/issues/162#issuecomment-175290781
.

[YashdalfTheGray]

Alright, open it back up. Sorry about that.

Yash Kulshrestha
[email protected]
(614)563-1163
Sent from my Nexus 6P
On Jan 26, 2016 6:53 PM, "Robert" [email protected] wrote:

It doesn't solve anything because we're not using it yet. There's still
work to be done.
On Jan 26, 2016 6:25 PM, "Yash Kulshrestha" [email protected]
wrote:

I figured that we've got a search endpoint now and we'll transition to
using that. It should be a lot more performant and we can modify it as we
see fit. This solves the front end search performance issue which is what
this was referring to.

—
Reply to this email directly or view it on GitHub
<
https://github.com/YashdalfTheGray/flintandsteel/issues/162#issuecomment-175290781

.

—
Reply to this email directly or view it on GitHub
https://github.com/YashdalfTheGray/flintandsteel/issues/162#issuecomment-175297019
.

[Mctalian]

Sorry I just like to have things open so we don't forget the work. As it stands the search end point doesn't quite support the extensive search options we currently support. We can rename this issue or open a different one that is a bit more specific to what needs to be done, but we need this work represented in a backlog item.