5 ms·
Yes, the store is terribly slow. That's almost certainly at the UI layer, which may indeed be something like Electron, which would explain the slowness. Node.j
by STRML 6y ago
Yes, the store is terribly slow. That's almost certainly at the UI layer, which may indeed be something like Electron, which would explain the slowness.
Node.js isn't slow, especially for this use case, but any sort of HTML-based layout definitely is.
- falcolas 6y agoNode - V8 - isn't slow when running on a device with a decent processor and fast RAM. The Switch is not such a device. IME, it's not the presentation, is the loading of assets into memory. Once the assets (like thumbnails, descriptions) are loaded, the display is as fast as always, but you scroll beyond what's cached and it turns back into molasses.
- arghwhat 6y ago"XYZ isn't slow if run on a fast enough processor" is an utterly useless statement. My personal gripe with the eShop is the horrible startup time (compare to the time it takes the settings application to open - part of this can be assigned to it being a web application indeed), lack of partial/incremental presentation, and possibly lack of prefetching. Asset loading causing bad UX is always a frontend problem.
- falcolas 6y agoAny interpreted language is going to its performance/memory barriers long before a compiled language as the CPU and memory shrink. It's inevitable; the interpretation is an unavoidable overhead. Sure, you can write slow code in any language, but the language will limit how fast your code can ever be. This from a Python fanboi, FWIW. I'd never try and use Python on an embedded device where performance matters, not only for UI responsiveness, but for battery life.
- colejohnson66 6y agoV8 and SpiderMonkey use JIT compilation, not interpretation
- arghwhat 6y agoV8 and SpiderMonkey extensively interpret, before functions are marked hot and traced, and every time they are deoptimized from failed guards.
- imtringued 6y agoThat only influences start up time.
- arghwhat 6y agoNo, it affects warm-up, which is not the same. JS is only JIT'ed if the interpreter decides that it has been running code enough for it to make sense, and then not even permanently. Some things will never JIT. Some things will JIT much later, leading to sudden CPU spikes later. And importantly, code will often deoptimize a few times, meaning that it drops back to interpreted to re-trace even if it had already optimized this code block. And as most web "applications" are loaded only to be thrown away as you finished reading fixed text, all of those resources were burnt for nothing. This includes an application like the eShop, which has limited need for JS for anything other than lightweight asset handling.
- Closi 6y agoIt’s amazing to me that the store is as slow as it is too - surely improving this could have a great payback in terms of sales.
- colejohnson66 6y agoIt’s extremely frustrating. I like looking at the new releases every few days, but if I wait too many days before checking, I have to go through screen after screen of scrolling and it freezes when it loads the new preview images.
- tokamak-teapot 6y agoI noticed this yesterday. I don't know why HTML would be to blame, as I've used web browsers on low power devices before and they can be very snappy. One thing I noticed was that when attempting to switch between e.g. 'Offers', 'New' and 'Highlighted' or whatever the headings are, there's a large lag / hangup. It certainly doesn't feel like they're working on keeping it fluid and snappy. That might not be a priority, but I'm certainly put off browsing and buying when it's unpleasant to do so. To be fair, it's worse on other consoles IME, and if I keep my browsing light, stay at the top of lists and don't get too impatient, it's okay.
- slmjkdbtl 6y agoIf it's true it's just terrible. The store is not that much of a complext software, yet they still decided to use these bloatware when they can just use their fine GPU and renderer natively.
- therealdrag0 6y agoIt’s slowness reminds me of blocking on UI threads.
- imtringued 6y agoI've never noticed HTML based layouts being slow unless someone explicitly designed a slow UI. The bigger problems are slow startup time and excessive RAM usage. Running multiple browser instances is not sustainable.