Skip to content

Performance TODO List

Jump to bottom Edit New page
peller edited this page Feb 17, 2012 · 21 revisions

  • Remove remaining sync dojo.xhr usage (metadata, resource, other)

  • Reduce calls to browser parser (trivial innerHTML calls with plain text?)

  • Build review and commenting into layer, remove any old build workarounds for review and commenting as a separate project

  • remove eval/sync xhr using in iframe in Context.js

  • Review network panel for individual network hits

    • e.g. propvieweffects.css #1673
    • Avoid multiple calls to getMetaRoot #844

  • Simplify document construction, avoid layouts

    • something funky is going on with the data: urls for images in the palette, but it's very late in the page load and does not seem to involve layout. It might be more efficient to tile them, or perhaps the delay is an artifact of the performance tool only?

  • Use JSON.parse and compliant JSON for *.json files (see dojo.contentHandlers for dojo.xhr)

  • Optimize user pages using dynamic AMD aggregator

    • impacts loading both the designer and preview modes, as well as the final product
    • quick solution would be to preload most/all of dijit (e.g. dijit-all) Does not really address the problem, nor does this account for other toolkits
    • optimize CSS requests (packaged, custom themes) inlining @import references, either per level or have a server task crawl the tree and create the batched response. Perhaps shrink whitespace, comments also
    • shrink and concatenate Javascript files using Dojo build tool or similar. May have significant performance problems of its own and not be suitable for davinci runtime.

  • Review images

    • convert palette category icons to data: images?
    • add anything to sprites?

  • Batch server requests to reduce latency

    • combine/inline package/widget JSON files on server
    • a REST protocol to return multiple JSON objects, CSS files, etc.
    • CSS for modeling (different than CSS requests from HTML, below) - could also combine, but in a structure which preserves filename info, or parse the model on the server and return as JSON
    • Individual widget metadata
    • Tree requests, per level?

  • Share Dojo/Dijit for themeeditor and design mode

  • More JS profiling

    • hotspots
    • repaints/layouts, many likely triggered by Dijit
    • create new (empty) document @ ~6 seconds

  • Memory profiling

  • Deferred loading

    • load tabs on demand, or prefetch - only load visible content on load (partially implemented)
    • Defer loading of views (Explorer, Review)
    • Separate ThemeEditor code in Context, lazy-load theme editor

  • Further build goals:

    • need strategy for build for ve and/or preview modes
    • build BBT "plugins" as layers
    • build across osgi plugins (or eliminate osgi plugins), i.e. davinci.review plugin
    • Use Google Closure compiler to shrink JS files. Seems to have better results than ShrinkSafe.
      • Or are there switches to ShrinkSafe that we can employ to achieve similar results to Closure?

  • consider removing osgi /jetty from server. would tomcat scale better? bypass servlets for simple resource fetching? what technology does orion use on their server?

  • Batch DOM updates using DocumentFragment

    • Instead of doing many successive DOM creations/insertions into the page Document, do them into a DocumentFragment, then add the DocumentFragment to the page Document. This provides much better DOM performance. (Dijit generally does this for us where "custom widgets" are used)

  • Performance Tools

Add a custom footer
Add a custom sidebar

Clone this wiki locally