Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Keeping Figma Fast: perf-testing the WASM editor

figma.com

Post reply on HN
Print view View original

71–80 of 99 posts

Re: Keeping Figma Fast: perf-testing the WASM editor

#71

Post by jauntywundrkind »

yellow_lead wrote: post #10

Seeing a 20% margin of error for some of their tests (due to VMs, noisy neighbors), makes me curious how others solve this problem. Dedicated hardware seems like a good investment, otherwise you need to constantly overcompensate with multiple runs.

This is definitely an interesting challenge!

Often CPU steals are visible in cloud environments. This could be useful for finding some noisy neighbor behaviors, and deciding to either adjusting expectations or rerun.

But things like IO, GPU or memory contestation also could be responsible. There are some fancy new-ish extensions for controlling memory throughput. Intel has Memory Bandwidth Allocation controls in their Resource Director Technology, which is a suite of capabilities all designed for observing & managing cross system resources. There's also controls available for setting up cache usage/allocation.

Re: Keeping Figma Fast: perf-testing the WASM editor

#72

Post by tobyjsullivan »

antoineMoPa wrote: post #68

That's kind of wild to me to see an app like Figma that's a commercial success, but also a demonstration of technical excellency. My brain automatically assumes that you can't pick both commercial success and technical excellency at the same time and must compromise on the latter to build more features. But maybe there is hope and users actually love the benefits of a better tech stack (performance, consistency, stab…

Your assumption was correct most of the time. 99% of tech startups are not innovating technically. They are applying existing tech to new problems. In these cases, quality engineering is low priority.

But there is that other 1% that is making new things possible. And if they are extremely lucky, they’ll build new tech and figure out how to turn it into a product. Figma is an example of what can happen when that mix hits.

Most technical innovations, though, will be licensed/sold/etc. to other companies which fall into the first group.

All that said, it turns out customers love software that works well. Startups (and most software companies, really) undervalue quality because it’s hard and not strictly necessary when there’s no direct competition.

Re: Keeping Figma Fast: perf-testing the WASM editor

#73

Post by jillesvangurp »

drewda wrote: post #4

Occasionally I wonder what could have happened to front-end web application development over the past few years if Figma had open-sourced their WebGL-based GUI library. We've had ~15 years of focus on the DOM with the progression of jQuery to Backbone to Vue, and many other libraries. At least what I've heard of the Figma approach almost sounds like the Adobe Flash/Flex runtime. That might only make sense for applica…

There are multiple ui frameworks now starting to target wasm. I'm keeping an eye on Jetbrain's multi platform compose, which is extending Google's Jetpack Compose for Android to IOS (alpha releas available with 1.5 released a few days ago), Desktop, and Wasm (experimental support available but a work in progress).

That will take a while to come together. Key blockers are removal of the feature flags currently needed to enable things like garbage collection in Firefox and Chrome and the completion of Kotlin 2.0 and it's new compiler (K2) which is currently available via a feature flag in the Kotlin 1.9 stable release. My estimation is that we're about 6 months away from those blockers being resolved. IOS support is likely to transition to beta around the same time. From there to being stable and well supported is probably another year or so.

But a lot of stuff works right now already. However, it's not suitable for production usage because of the early development status the various bits and pieces you need and the need for toggling browser feature flags.

There are some nice examples of IOS support in the recent release notes for compose web: https://blog.jetbrains.com/kotlin/2023/08/compose-multiplatf...

They don't really mention Wasm there as this mostly focuses on the IOS support. They had a lot of presentations about that at kotlin conf and the compose web channel in the kotlin slack is very active.

Basically, anyone currently doing mobile development that is used to modern UI frameworks for that, will soon be able to target browsers effortlessly without compromising on their UI frameworks. Compose is one of the frameworks. But there are others. I've seen some nice kotlin-js frameworks targeting canvas and vector graphics. Doodle is a nice example: https://nacular.github.io/doodle/. I have not used that yet but it looks quite slick. A lot of kotlin-js stuff will transition to wasm once the compiler stabilizes.

Web developers seem to be mostly unable to see beyond their comfort zone of DOM/CSS/JS. There are alternative ways of doing UI/UX that are common outside of browsers. Applying that in a browser is transitioning from impossible (a few years ago) to being hard but very feasible (the last few years) to being easy, very common, and widely supported across different developer ecosystems (the next few years). Not a matter of if but when.

Re: Keeping Figma Fast: perf-testing the WASM editor

#74

Post by fulafel »

capableweb wrote: post #55
failuser wrote: post #43

Earlier quoted context omitted.

I’ve seen this happen, but I don’t understand why that is possible. Chrome tabs are separate process, how can one tab freeze the whole browser even when running the worst code in existence?

> I’ve seen this happen, but I don’t understand why that is possible. Chrome tabs are separate process, how can one tab freeze the whole browser even when running the worst code in existence? Because if anything takes up 100% of CPU, other things starts being unresponsive as there is not enough CPU to go around. Happens easily when dealing with concurrency and parallism, which I'm guessing Figma happily uses.

This is not the case. Maybe people have already forgotten what using computers was like when everyone had only 1 core, but having a few desktop apps pegging their share of cpu doesn't hurt interactivity much even on single-core computers.

Re: Keeping Figma Fast: perf-testing the WASM editor

#75

Post by bsder »

jjcm wrote: post #23
bsder wrote: post #9

Earlier quoted context omitted.

Figma was considered ... good? Every time I have used it, it feels incredibly laggy with a crapton of useless animations. Maybe it's better on Windows?

PM over here at Figma - would love to know where you're experiencing lag / where you're seeing useless animations. Overall we're pretty minimal when it comes to animations in product (i.e. here's a quick 22s recording of navigating between screens/opening properties panels in product today: https://video.non.io/video-2940009905.mp4 ) as we really want to convey that the app is snappy/performant. Definitely keen on di…

Chrome on Ubuntu using your "Diagram Basics" template.

Dragging any object is laggy--particularly so over the slightly pinkish/purplish background area.

Re: Keeping Figma Fast: perf-testing the WASM editor

#76

Post by DanielHB »

antoineMoPa wrote: post #68

That's kind of wild to me to see an app like Figma that's a commercial success, but also a demonstration of technical excellency. My brain automatically assumes that you can't pick both commercial success and technical excellency at the same time and must compromise on the latter to build more features. But maybe there is hope and users actually love the benefits of a better tech stack (performance, consistency, stab…

Sometimes commercial success is due to technical excellence. Especially in overcrowded fields just being better is enough.

Re: Keeping Figma Fast: perf-testing the WASM editor

#77

Post by yellow_lead »

imslavko wrote: post #14
yellow_lead wrote: post #10

Seeing a 20% margin of error for some of their tests (due to VMs, noisy neighbors), makes me curious how others solve this problem. Dedicated hardware seems like a good investment, otherwise you need to constantly overcompensate with multiple runs.

Hey, I am one of the authors of the article and the systems described. The default 20% margin of error is indeed pretty wide, and it is intended to catch large obvious regressions (e.g. an algorithm accidentally becoming quadratic instead of being linear) As we described in the blog post, we have the second system based on the real hardware. This system is on-demand. If an engineer has a suspect commit or an experime…

Thanks for your reply. Can you share how these laptops are managed? I took another look at the article but didn't find that information there.

I.e I'm curious if there's a cloud provider managing them for you or you guys keep them in a closet somewhere.

Re: Keeping Figma Fast: perf-testing the WASM editor

#78

Post by yellow_lead »

jauntywundrkind wrote: post #71
yellow_lead wrote: post #10

Seeing a 20% margin of error for some of their tests (due to VMs, noisy neighbors), makes me curious how others solve this problem. Dedicated hardware seems like a good investment, otherwise you need to constantly overcompensate with multiple runs.

This is definitely an interesting challenge! Often CPU steals are visible in cloud environments. This could be useful for finding some noisy neighbor behaviors, and deciding to either adjusting expectations or rerun. But things like IO, GPU or memory contestation also could be responsible. There are some fancy new-ish extensions for controlling memory throughput. Intel has Memory Bandwidth Allocation controls in thei…

Yeah, I think I/O has bit us before. Running on AWS, you may randomly get a huge spike in I/O latency (maybe Amazon adjusted the physical hardware, drive failed, etc) and have no idea why.

Re: Keeping Figma Fast: perf-testing the WASM editor

#79

Post by maccard »

sa46 wrote: post #46
steve_adams_86 wrote: post #33

Earlier quoted context omitted.

I thought this sounded way too low but the most generous figure I can find is 12 per second in 2022. What the hell? I thought it would be more. Should I have thought that? I guess not.

6 bookings per second at $200 per booking is $103M processed per day. Each booking likely represents dozens to hundreds of requests. Then, for every visit resulting in a booking there’s probably hundreds of non-booking visits.

> 6 bookings per second at $200 per booking is $103M processed per day.

I don't doubt that they don't prcess a lot of money - that's besides the point.

They're a cookie cutter CRUD app (that happens to process a lot of money) that takes _hundreds_ of requests and 12 seconds to load on a 32 core workstation with a gigabit fibre internet connection. They have no business writing a blog on performance engineering.

Re: Keeping Figma Fast: perf-testing the WASM editor

#80

Post by wryanzimmerman »

seanthemon wrote: post #47
failuser wrote: post #43

Earlier quoted context omitted.

I’ve seen this happen, but I don’t understand why that is possible. Chrome tabs are separate process, how can one tab freeze the whole browser even when running the worst code in existence?

Figma is beyond chrome, it's a quantum app: it's both in a state that will lock up my pc while everyone on zoom waits for the screen to load and a journey in following designer's instructions: "no a bit more left, no actually right, ok go down, no up, ok back go the left a bit, ok here it is!", same vibe as rally racing lol

For #1: don’t use it in chrome, download the app (it seems like it takes advantage of the wrapper pretty well); for #2, just click on the designer’s name in the top corner to zoom your screen to theirs and let them drive for a second!
Post reply on HN