This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-02-17
Channels
- # beginners (26)
- # calva (7)
- # cider (6)
- # cljs-dev (7)
- # clojure (86)
- # clojure-europe (1)
- # clojure-finland (1)
- # clojure-spec (3)
- # clojure-uk (11)
- # clojurescript (18)
- # cursive (6)
- # data-science (1)
- # emacs (13)
- # fulcro (34)
- # juxt (8)
- # nrepl (6)
- # off-topic (11)
- # pathom (25)
- # re-frame (13)
- # reitit (11)
- # shadow-cljs (4)
- # spacemacs (3)
I'm loading lots of data into app-db. Probably around 16mb of csv that I convert to a datastructure. I run some validation and pull up to 15 invalid rows and display them. If the number of invalid rows are less than 15, I show the remaining number of top rows. I eventually send this data to an API. The app freezes completely when I load it in (via paste on a div) which is acceptable given the size. However afterwards the app is sluggish and freezes frequently for about 30 seconds. After that everything seems fine. This freezing occurs on views where the subscription accessing the data isn't even rendered. Is there any way I can improve this? I would even consider moving the data out of the app-db and somewhere else
You should first investigate what is it that takes long time. Then you should improve the part of the app that takes long.
also - did you read this page: https://github.com/Day8/re-frame/blob/master/docs/Solve-the-CPU-hog-problem.md?
I'm not rendering all this data to the view ever. Only 25 small rows of it
first thing to check would be the Chrome DevTools profiler, or similar. see where the time is being spent.
it might be a general JS performance problem, not anything wrong with your subscriptions.
@caleb.macdonaldblack if you use re-frame-10x, it will show you which subscriptions are running
It sounds like there might be some subs running in places where you don't expect it
Also, do you have any middleware running which are doing diffs or other potentially expensive operations?
But I'd second @braden.shepherdson’s suggestion, it should be very clear what is causing a 30 second hang in devtools profiler.
Protip: you can give an anonymous function a name if you provide it after fn
. E.g. (fn [xy] ...)
=> (fn xy-handler [xy] ...)
, and it will show up with that name in devtools profiler
I don't have any middleware running. And thanks for the tip, I'll take a look now and see if I can work it out.
Wow thanks everyone. I honestly thought given the size of the data It wouldn't be possible to optimise but I can see that it its. It was a subscription causing it to slow down. I've moved that work to an event handler as https://github.com/Day8/re-frame/blob/master/docs/Solve-the-CPU-hog-problem.md suggested. I'm going to batch it now and that should fix the remaining issues.