3 ms·
> Composite views in the app take 1-2s to render on an 8-core Xeon and a T1 line Those composite views have lots of assets. A second or two seems reasonable ov
by hackmiester 12y ago
> Composite views in the app take 1-2s to render on an 8-core Xeon and a T1 line
Those composite views have lots of assets. A second or two seems reasonable over a 1.5 Mbit/s connection. (Unless I am thinking of another view than the one you mean.)
- Pxl_Buzzard 12y agoI assume "composite views" -> "playlists." I have a 3,200 song playlist that takes 5-10 seconds to load, whereas it was <1 second prior to the latest update. Maybe it was caching a local copy and now it always pulls from the server?
- j42 12y agoSorry, that was a slip up on my part :). It's actually a 150Mbit/s line, and I usually get ~20MB/s solid throughput downstream (megabytes) hence the weirdness. To expound on the other reply, he's probably right. My guess is they made a major push to refactor/simplify the codebase and in an effort to remain 'stateful' they shifted the balance a little bit too far toward the network over local caches and stores. Even still it could work, as long as you can properly pre-render the last-synced state and decouple any view elements from the synchronicity of the actual data streams and JSON metadata. The version prior did this perfectly. Anyway my hope is a lot of this will be fixed in the near future and with any luck the dev outreach will improve--IMHO that's the only area they have really been consistently lacking.