Kioo performance with complex HTML

[Oliver Mooney]

Hi,

I'm using Kioo & Reagent to add feedback to a form, so that when a user fills it out they receive indications if their input is valid. The forms are already created in HTML, and I'm pulling them into Kioo as templates via deftemplate.

The problem is that forms of certain complexity take a long time to attach to the webpage, and others take so long the browser times out. For example, the following HTML snippet

<form>
 <fieldset>
   <legend>Legend</legend>
   <div>
     <div>
       <label for="outcomescompletiondate">Date input label</label>
       <input id="outcomescompletiondate" name="outcomescompletiondate" type="date">
     </div>
   </div>
 </fieldset>
</form>

takes about five seconds to appear on the page after the render-component call, in the latest version of Safari on a late 2014 mac mini (2.6 GHz i5, 8 gb ram).

The cljs I'm using is:

(ns adaptdb.outcomes  
  (:require [reagent.core :as r :refer [atom]]
            [kioo.reagent :as k])
  (:require-macros [kioo.reagent :refer [defsnippet deftemplate]]))

(deftemplate min-test "adaptdb/views/eTemplates/min-test.html" []
             {[:label] (k/content "Updated label.")})

(r/render-component [min-test] (.getElementById js/document "content"))

The actual HTML file I'm hoping to use is a complex form of about 250 lines. The browser page is reloaded by the browser before it appears.

The same files work without issue for server-side rendering of the form using Enlive.

Simplifying the HTML improves things - a shallower structure seems to render without issue. Is there a complexity limit on the HTML Kioo will handle? This is using the latest version, 4.1.0-SNAPSHOT.

Any help would be gratefully received!

Thanks,
Oliver.

[Creighton Kirkendall]

Oliver,

Can you point me to a repo.  I have not heard of any type of performance issue like this before.  Something odd feels like it is going on.  If you can put together a small example in a repo I will certainly help diagnose what is going.  

Creighton

--

---
You received this message because you are subscribed to the Google Groups "Enfocus" group.
To unsubscribe from this group and stop receiving emails from it, send an email to enfocus+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Oliver Mooney]

Thanks Creighton. I created a repo here:

https://github.com/OliverM/kiooform

It's a fresh project but it exhibits the same issues.

Oliver.

[Creighton Kirkendall]

Oliver,

This is very strange.  Chrome seems to be fine with the display being almost instantaneous.  Safari seems to be actually hanging on something.  Kioo doesn't do any magic it just straight functional calls to react components.  I will dive in and see if I can't narrow down what is causing safari so many issues.

Creighton

[Creighton Kirkendall]

Oliver,

I am not sure what safari is doing but it's not good.  

Chrome: 4ms - kiooform$core$minform

Safari: 2.34s - kioofrom$core$minform

Crieghton

[Oliver Mooney]

Wow. That's an incredible delta. I don't know if it's at all related but it reminds me of another performance delta in re-com,

Re-com is a set of components for React based on the flexbox CSS layout model. It's very snappy in Chrome but much slower in Safari. They've a demo site here:

http://re-demo.s3-website-ap-southeast-2.amazonaws.com

How can I help pin it down further? It seems to be nested structures which cause the slow down, long shallow structures appear without issue, so it's simply template length.

[Creighton Kirkendall]

Oliver,

There are some other oddities here with safari.  Even in its performance tools it won't go any deeper than  kioofrom$core$minform.  So it's not a call it's doing that is taking the time it's the actual initialization of the function call.   It might be the creation of objects but it feels like safari's JIT is getting confused by the javascript produced.

Creighton

[Oliver Mooney]

I've not kept up with developments in the cljs compiler, would something there have changed that's causing Safari to choke? Would it be worthwhile reverting to an earlier cljs version to test? 

[Creighton Kirkendall]

Oliver,

There seems to be more going on here than just hanging on javascript.  It actually hangs everything including the debug tools.  It doesn't even appear to hang in the same place each time.  I have a feeling it is hanging when it's parsing the javascript not when it's running.

Creighton

[Oliver Mooney]

There's no way that can be unique to Kioo, surely?

[Creighton Kirkendall]

Oliver,

No I don't think this is specific kioo, but the compiler in kioo is generating code that seems to trigger it.   I saw something similar on another project where kioo wasn't used but I can't remember how we fixed it.

Creighton

[Oliver Mooney]

Firefox has no issues. I've tried reverting to earlier versions of Kioo but the project won't compile with 0.4.0 let alone earlier ones, presumably due to dependency issues I'm not sure how best to untangle.

Is Safari essentially unsupported until this is pinned down? If I can do anything to assist please don't hesitate to ask!

Oliver

[Creighton Kirkendall]

Oliver,

I am experimenting with generating slightly different code.  I still am not sure even what is causing the issue.  The performance tools do not show any thing lower than the initial call to the template.  

Creighton

[Alexander Gunnarson]

The reason for this, I found after some macroexpansion and careful debugging, is that Safari can't handle functions beyond a certain length/size. Kioo's `deftemplate` just generates far too much code (50 LOC -> 4000 LOC in my case). Chrome, Firefox, and perhaps others are okay with that, but Safari just won't finish parsing it. The solution is to either break up the `deftemplate` definition or (better) redefine the `deftemplate` macro to not generate so much code and use function calls instead of inline macroexpansion.