{"action":"created","issue":{"url":"https://api.github.com/repos/percolatestudio/publish-counts/issues/59","labels_url":"https://api.github.com/repos/percolatestudio/publish-counts/issues/59/labels{/name}","comments_url":"https://api.github.com/repos/percolatestudio/publish-counts/issues/59/comments","events_url":"https://api.github.com/repos/percolatestudio/publish-counts/issues/59/events","html_url":"https://github.com/percolatestudio/publish-counts/issues/59","id":99866873,"number":59,"title":"Search speed greatly reduced when using Counts.publish()","user":{"login":"Diginized","id":4769441,"avatar_url":"https://avatars.githubusercontent.com/u/4769441?v=3","gravatar_id":"","url":"https://api.github.com/users/Diginized","html_url":"https://github.com/Diginized","followers_url":"https://api.github.com/users/Diginized/followers","following_url":"https://api.github.com/users/Diginized/following{/other_user}","gists_url":"https://api.github.com/users/Diginized/gists{/gist_id}","starred_url":"https://api.github.com/users/Diginized/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Diginized/subscriptions","organizations_url":"https://api.github.com/users/Diginized/orgs","repos_url":"https://api.github.com/users/Diginized/repos","events_url":"https://api.github.com/users/Diginized/events{/privacy}","received_events_url":"https://api.github.com/users/Diginized/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":3,"created_at":"2015-08-09T05:31:26Z","updated_at":"2015-08-10T22:13:19Z","closed_at":null,"body":"First, thanks for creating this package, I was accomplishing some of this with custom method calls but this offers many handy features.  I also find it much easier to use than the many others out there that seek to help with counts and paging.  \r\n\r\nThe one downside is that it seems to add a lot of lag to my searches and it's doing so in a blocking (synchronous) fashion.  I don't really care if the total count takes a second or two to respond, if it can run in the background and just update the template when it's ready.  But holding up the rest of the app is a bummer.  Is there's a way to get this to run asynchronously?\r\n\r\nExample: \r\nThe following code executes and returns/displays 30 records to browser almost instantly (at most 5ms after button click)\r\n```\r\n\tMeteor.publish(\"search\", function (searchParameters) {\r\n\t\tcursor = Contacts.find(searchParameters); \r\n\t  \t//with Counts disabled, results on screen feel instant. \r\n\t  \t//counts = Counts.publish(this, 'totalSearchResultsCounter', Contacts.find(searchParameters));\r\n\t  \treturn cursor;\t \r\n\t});\r\n\r\n```\r\n\r\nThe same code with Counts.publish() added is taking between .5 and 2 full seconds before the first signs of life are hitting the browser, and then things drop in sequentially (the total count from Counts.publish (y), then the count of records (x) on page (showing x of y records), then the records themselves)  \r\n```\r\n\tMeteor.publish(\"search\", function (searchParameters) {\r\n\t\tcursor = Contacts.find(searchParameters); \r\n\t  \t//with Counts enabled, results have a lot of lag because it's blocking everything else form running. \r\n\t  \tcounts = Counts.publish(this, 'totalSearchResultsCounter', Contacts.find(searchParameters));\r\n\t  \treturn cursor;\t \r\n\t});\r\n```\r\n\r\nAny suggestions on how to improve?   Thanks again! "},"comment":{"url":"https://api.github.com/repos/percolatestudio/publish-counts/issues/comments/129631185","html_url":"https://github.com/percolatestudio/publish-counts/issues/59#issuecomment-129631185","issue_url":"https://api.github.com/repos/percolatestudio/publish-counts/issues/59","id":129631185,"user":{"login":"Diginized","id":4769441,"avatar_url":"https://avatars.githubusercontent.com/u/4769441?v=3","gravatar_id":"","url":"https://api.github.com/users/Diginized","html_url":"https://github.com/Diginized","followers_url":"https://api.github.com/users/Diginized/followers","following_url":"https://api.github.com/users/Diginized/following{/other_user}","gists_url":"https://api.github.com/users/Diginized/gists{/gist_id}","starred_url":"https://api.github.com/users/Diginized/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Diginized/subscriptions","organizations_url":"https://api.github.com/users/Diginized/orgs","repos_url":"https://api.github.com/users/Diginized/repos","events_url":"https://api.github.com/users/Diginized/events{/privacy}","received_events_url":"https://api.github.com/users/Diginized/received_events","type":"User","site_admin":false},"created_at":"2015-08-10T22:13:19Z","updated_at":"2015-08-10T22:13:19Z","body":"@boxofrox , you are correct, the lag I'm citing is only with the initial pageload of data.  I think you are probably also correct about .count() being the slow part.  Here's what I've learned: \r\n\r\n* Your first test to try cursor.count() is a good suggestion.  That definitely accounts for a noticeable amount of the lag.   The remainder is probably stuff like updates to the template which is to be expected. \r\n\r\n* Your suggestion #3 above (two cursors) performs about the same as my initial code and your cursor.count() example, so there doesn't seem to be any benefit to creating two separate cursors.  \r\n\r\n* I'm guessing the real difference in performance here is that when not using the Counts or cursor.count() I'm fetching on only the first 30 rows {limit: 30} and that's probably why the records are coming back to the client so fast.  When doing one of the count methods, the limit is ignored because we're trying to get the total count, and that total count is just slower. \r\n\r\nI don't really understand the observer.added parts.  This database doesn't change too often (very small number of users doing data input) so I'm not even as worried about the reactive updates or certain how to test them. \r\n\r\n_Regarding Regex/denormalized:_ I've definitely thought about doing the denormalized names instead of regex searching, like you suggested, but so far the regex searching is working fast enough (when a count isn't happening) that I feel it's not causing any troubles.  If the database gets into the 10s of millions of records then this is something I thought I might have to look into.  \r\n\r\nConclusion (for now):  Your suggestion #2 above (The fix described in issue #58 ) definitely has faster performance than any of the things discussed above.  If you do make that change and allow the search values to pass through, I think that's a big help for performance. I have a feeling there will be a negative side-effect to it, which I'll note when I reply to that thread in a min, so maybe treating that behavior as an option is the best of all worlds.  "}}