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

21–30 of 99 posts

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

#21

Post by imslavko »

titzer wrote: post #3

Really awesome work! If the authors happen to drop by, I'd be curious if some of the work in their pipeline might be able to help for other types of GUI applications with Wasm. I'm also very curious to see what role, if any the Wasm engine's performance plays in the overall story, and be able to distill out any key workloads that can help Wasm engines improve.

Thank you for your comment!

WASM gave Figma a lot of speed by default for a lot of perf-sensitive code like rendering, layouts, applying styles and materializing component instances, our GUI code is mostly React and CSS.

WASM engine performance has not been a problem for us, instead we are constantly looking forward improvements in the devex department: debugging, profiling and modularization.

One of the largest challenges of the platform we face today is the heap size limit. While Chrome supports up to 4GB today, that's not yet the case for all browsers. And even with that, we are still discovering bugs in the toolchain (see this recent issue filed by one of our engineers) https://github.com/emscripten-core/emscripten/issues/20137

The challenge of the perf-testing at scale in our company is helping developers to detect perf regressions when they don't expect them - accidental algorithmic errors, misused caches, over-rendering React components, dangerously inefficient CSS directives, etc.

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

#22

Post by skhameneh »

Evan Wallace (former CTO) was a WASM pioneer IMO, he has plenty of excellent explorations and works shared on GitHub. I don't know Evan, but I've greatly appreciated stumbling into his works when exploring SharedArrayBuffer and what was once bleeding edge browser performance.

https://github.com/evanw

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

#23

Post by jjcm »

bsder wrote: post #9
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…

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 diving in if you're experiencing otherwise. Happy to chat here or my email is jake@figma.com.

Regarding platform specific performance - it shouldn't affect things as long as you have GPU acceleration enabled. The majority of us over here at Figma are using OSX FWIW.

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

#24

Post by jjcm »

imslavko wrote: post #21
titzer wrote: post #3

Really awesome work! If the authors happen to drop by, I'd be curious if some of the work in their pipeline might be able to help for other types of GUI applications with Wasm. I'm also very curious to see what role, if any the Wasm engine's performance plays in the overall story, and be able to distill out any key workloads that can help Wasm engines improve.

Thank you for your comment! WASM gave Figma a lot of speed by default for a lot of perf-sensitive code like rendering, layouts, applying styles and materializing component instances, our GUI code is mostly React and CSS. WASM engine performance has not been a problem for us, instead we are constantly looking forward improvements in the devex department: debugging, profiling and modularization. One of the largest chal…

+1 to heap size limit speaking as a PM over here at Figma. We regularly see files with hundreds of thousands of layers, and trying to keep those enormous files under 2GB of memory for usage across all supported browsers is a constant struggle.

Would love to see that cap get raised across the board, it'd enable us and others to do so much more.

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

#25

Post by maccard »

rozap wrote: post #18
maccard wrote: post #13

Earlier quoted context omitted.

Airbnb is a great example of a terrible experience that just keeps getting worse. It makes my M1 Mac, my 32 core workstation and my top of the line android device chug.

The shininess of the engineering blog and the actual product seem to be completely disconnected. All the major players (Airbnb, Instagram, Facebook, Twitter) go on about all these often genuinely impressive perf optimizations, but if you actually try the product they're borderline unusable. It's pretty clear that the blogging is just a clout chasing exercise, but the cognitive dissonance is still palpable.

I think Airbnb is the worst offender by far though. Instagram, Facebook and Twitter (just using your examples) operate very dynamic applications at a global scale. AirBnB is a crud app with almost no dynamic content other than the booking system. According to the first site I saw online, they process 6 bookings per second, which I could handle on literally anything with an internet connection. Of all of them, its the one I understand the least.

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

#26

Post by ShadowBanThis01 »

We didn't have a problem with Figma's technology, but we did have problems with their UI. For example, it confused "teams" and "projects," making managing your work and granting access to people a baffling pain in the ass. It took a week of E-mailing people for me to gain the necessary access to my own team's files when we adopted Figma, most likely because of the inept segregation and presentation of these entities.

Has there been any UI overhaul since acquisition?

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

#27

Post by ed_elliott_asc »

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…

Hey,

I worked on a really perf sensitive system and for perf tests we would run the last x commits each time to get rid of the busy vm syndrome.

It meant that the margin of error could be much less.

You might want to consider it as a mid way step between vm’s and scheduling on laptops (those poor laptop batteries!)

Ed

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

#28

Post by School-Cotton »

rozap wrote: post #18
maccard wrote: post #13

Earlier quoted context omitted.

Airbnb is a great example of a terrible experience that just keeps getting worse. It makes my M1 Mac, my 32 core workstation and my top of the line android device chug.

The shininess of the engineering blog and the actual product seem to be completely disconnected. All the major players (Airbnb, Instagram, Facebook, Twitter) go on about all these often genuinely impressive perf optimizations, but if you actually try the product they're borderline unusable. It's pretty clear that the blogging is just a clout chasing exercise, but the cognitive dissonance is still palpable.

From experience at Facebook: there are extremely good people working on performance and making heroic optimizations. The blog content is real. However, these are necessary precisely because the politics and culture of the organization make it impossible to avoid bloat that accumulates faster than the small minority of perf-conscious folks can improve things.
Post reply on HN