Loading 1100 clickEl's is very slow

[mpdairy]

I have a list of 1100 users and I tried to make a button for each one (using clickEl) that returned the userId to a parent element, which I would use to jump to a new route. But it's extremely slow loading that many click elements. It could handle a couple hundred well, but approaching 1000 the performance really plummets. Once they load up, it's pretty responsive, but loading them take at least 10 seconds.

For now I just made a fake button function that uses a href instead of Concur's events machinery:

linkButton :: String -> String -> Widget HTML ()
linkButton label url =  el_ E.a [ A.href . JS.pack $ url ]
                        $ el E.button [ A.class_ "pure-button" ] [ text label ]

which is really fast and fine for now since I'm just jumping to an URL, but at some point I'm sure it would be nice/essential to be able to use clickEl's or some other event listener for a big list.

[ajnsit]

Thanks for reporting this. 10 seconds is just unacceptable! Is it possible for you to share the code?

[mpdairy]

Thanks, I'll make a simplified version that demos it and paste it here later today.

[mpdairy]

Ok here's a widget that will just load a bunch of buttons:

import Concur.VDOM ( HTML, button, el, el_ )

slowList :: [Int] -> Widget HTML Int
slowList = el E.div [] . fmap buttonize
  where
    buttonize n = el_ E.div [] $ do
      button $ show n
      return n

If I call it with slowList [0..500] it takes a couple seconds to load, but if I do slowList [0..2000] Chrome will eventually crash like the page is unresponsive, but if you click "Wait" it will eventually load.

[saurabhnanda]

Randomly listening to the conversation. What all is concur doing behind the scenes here?

…

On 21-Oct-2017 5:30 AM, "Matt Parker" ***@***.***> wrote: Ok here's a widget that will just load a bunch of buttons: import Concur.VDOM ( HTML, button, el, el_ ) slowList :: [Int] -> Widget HTML Int slowList = el E.div [] . fmap buttonize where buttonize n = el_ E.div [] $ do button $ show n return n If I call it with slowList [0..500] it takes a couple seconds to load, but if I do slowList [0..2000] Chrome will eventually crash like the page is unresponsive, but if you click "Wait" it will eventually load. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#6 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABu0SBXhu5jE3rQ9THllh68ET0STCxZks5suTQGgaJpZM4P__F6> .

[ajnsit]

@mpdairy I added the benchmark code here - https://github.com/ajnsit/concur-benchmarks/blob/master/src/ClickList.hs

To get another data point - Which browser are you on? From my quick testing, there seems to be a massive performance difference among browsers - Firefox (I use nightly) was able to load [0..5000] widgets in 1-2 seconds with performance becoming inconsistent beyond that. Chrome and Safari were both extremely slow in comparison (though neither froze).

@saurabhnanda There are a whole bunch of things happening because of the highly abstracted interface for Concur. Here's what I see as areas of potential improvement -

1. String packing/unpacking (JSS.String <-> String)

2. A button can have arbitrary children which may have their own events. So each button is effectively a <button> wrapper over a list of child widgets. We capture the events generated by the top level button and wrap them in a Left, and all the events from the child widgets in a Right. In this case, we only have static text as the contents of the button, but it's still treated as a full widget. Then the Left and Right events are joined with <|>. All this has some (non-trivial) overhead. I went ahead and removed this abstraction from text only buttons - 4dbf7dc.

3. The largest benefit would definitely come from optimising the render cycle. All the button widgets are orrd together sequentially, and their DOM views populated . This currently has no batching, and rapidly and repeatedly modifying the DOM has known performance implications.

4. There are a lot of STM threads created which may or may not have a significant performance impact.

5. There does not seem to be excessive thunking or memory leaks. But it's still an area to look into.

[ajnsit]

Okay I'm pretty certain I understand why this is happening. Will push a fix soon-ish.

[ajnsit]

@mpdairy I just pushed a change that fixes this in concur-core and then specifically for concur-vdom text button widgets. Please try it and let me know if that fixes the issue for you. I'll soon push fixes for other inbuilt widgets (it's a trivial, but tedious change).

[ajnsit]

Keeping this open until all the widgets are converted.

[ajnsit]

I uploaded the benchmark demos here - https://ajnsit.github.io/concur-benchmarks/

[ajnsit]

@saurabhnanda BTW I added another benchmark where I pretty much copied your JS benchmark code for miso, and tweaked it a bit to get it to compile with concur. You can check the source and demo.

[mpdairy]

Hey thanks! That update made my button list really fast. Even the list with 4500 users loaded quickly. I didn't measure it, but the new buttons seem just as fast as the fake linkButton button I pasted at the top of this thread. What was the change you made to speed them up so much?