[HN Gopher] Keeping Figma Fast: perf-testing the WASM editor
       ___________________________________________________________________
        
       Keeping Figma Fast: perf-testing the WASM editor
        
       Author : imslavko
       Score  : 174 points
       Date   : 2023-08-30 16:01 UTC (6 hours ago)
        
 (HTM) web link (www.figma.com)
 (TXT) w3m dump (www.figma.com)
        
       | [deleted]
        
       | yeldarb wrote:
       | Nice post. Figma's engineering blog looks great; right up there
       | with Airbnb's and Etsy's which I also enjoy.
        
         | maccard wrote:
         | 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.
        
           | rozap wrote:
           | 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.
        
             | umanwizard wrote:
             | 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.
        
             | maccard wrote:
             | 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.
        
               | steve_adams_86 wrote:
               | 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.
        
         | culi wrote:
         | No RSS feed though afaict :(
        
       | ShadowBanThis01 wrote:
       | 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?
        
       | chrisdbanks wrote:
       | Is Figma fast? I see huge lag on loading files. Sometimes images
       | don't load for 10+ seconds after the file opens. Based in EU we
       | often don't get thought about in testing.
        
         | samsolomon wrote:
         | Sounds like y'all might have a lot of large images or raster
         | files?
         | 
         | That I have files with enormous thousands of components and
         | Figma doesn't miss a beat. If you're able to get vector
         | versions of those, then the speed shouldn't be an issue.
         | Obviously if there are a lot of photos, that might be tough.
        
         | mortenjorck wrote:
         | The answer to "is x fast?" is always "compared to what?"
         | 
         | Having been a long-time user of Figma's somewhat-trailing (at
         | this point) competitor, Sketch, speed is surprisingly one of
         | Figma's most immediately-apparent advantages despite being web-
         | based rather than MacOS-native.
         | 
         | At a previous job, we had a Sketch file that contained more or
         | less an entire B2B app, and at hundreds of megabytes, it took
         | tens of seconds to load (not asynchronously, either, blocking
         | the UI until the whole thing was in memory). A similar
         | everything-file at a more recent job where we used Figma was
         | like night and day: something like three seconds until the file
         | was usable, and perhaps a few more seconds for any big images
         | to load.
         | 
         | Then there's Figma's upstart competitor, Penpot. In my initial
         | explorations, it felt about as responsive as Figma, but when I
         | loaded one of their tutorial files - not even a mega-B2B-app
         | file - everything slowed considerably. The load time wasn't
         | bad, but the frame rate for simply scrolling around the
         | artboards dropped like a rock. While I'm bullish on Penpot,
         | they have a _long_ optimization road ahead of them.
        
       | titzer wrote:
       | 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.
        
         | imslavko wrote:
         | 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.
        
           | jjcm wrote:
           | +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.
        
       | yellow_lead wrote:
       | 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.
        
         | imslavko wrote:
         | 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 experimental change that
         | might affect performance, they would schedule a 30min-1hr run
         | on that queue, where we run selected benchmarks 9-15 times each
         | on laptops of various strength. In this configuration, the
         | margin of error is closer to 2-3% from our observations so far.
         | To get more confidence, you would want to run even more trials,
         | typically we advise 9 iterations, though.
         | 
         | We also do all our daily benchmarking on those laptops too.
         | 
         | Edit: in addition to preventative testing, we also track
         | production metrics in a similar way as described by the sibling
         | comment
        
           | ed_elliott_asc wrote:
           | 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
        
             | imslavko wrote:
             | That's a good way to address the noise on VMs! We do
             | something different but in a similar spirit: when we
             | compare to the main branch, we calculate the baseline based
             | on 1-2 weeks worth of historical data on main (we identify
             | the latest step change with a simple linear regression).
             | This way we approximate the baseline based on ~100 data
             | points which also helps to address the variance.
             | 
             | Of course re-running the code from main and the PR on the
             | same VM side by side would be the best, and it would cost a
             | lot more money (especially once you factor in GPUs). We
             | considered it but opted to the strategy I outlined above,
             | it's mainly a trade-off between accuracy vs costs
        
         | koenbok wrote:
         | At Framer (framer.com) we actually had a bit lower variance (I
         | think it was closer to 15%) after spending three months of
         | solid engineering, ending up with a dedicated Mac Mini running
         | Chrome.
         | 
         | Apart from the admin overhead (things got stuck on OS updates)
         | we ended up abandoning the setup because the variance was too
         | big to get anything useful out of running tests for every pr.
         | 
         | The most reliable way for us to monitor performance today is to
         | count slow frames (>16ms) across all actual users and divide
         | them by total time spent in app. It's a rough proxy, but pretty
         | accurate at showing us when we mess up.
        
       | drewda wrote:
       | 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 applications with high levels of
       | information density and snappy reactivity requirements like Figma
       | or Google Docs or a web map -- not for content-focused websites.
       | Still, it's interesting to wonder if our arguments would be more
       | interesting these days if we were discussing those types of
       | approaches, rather than just fighting about React vs. Svelte, or
       | this JavaScript module loader vs. that one...
        
         | maccamey wrote:
         | Couldn't agree more. Would love more discussion of stuff like
         | this in front end
        
         | bsder wrote:
         | 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?
        
           | jve wrote:
           | Not for me... well, I'm on Windows.
           | 
           | It is currently the best tool for me, as a non designer, to
           | smash together (design) icons and export in my choice of
           | format.
        
           | hifix wrote:
           | I use it daily on Windows and I have to say it seems pretty
           | fast. Never noticed any lagging or unnecessary animations.
        
           | jjcm wrote:
           | 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.
        
         | andy_ppp wrote:
         | Could someone compile Skia to WASM and add a layer for some UI
         | niceties like flexbox? I wonder what the layer they have
         | consists of.
        
         | preommr wrote:
         | It would not.
         | 
         | 1. Wasm based UI libraries exist already, checkout makepad [0]
         | for example.
         | 
         | 2. Web app standards are way higher than when flash was around.
         | I highly doubt there would be any serious discussion that would
         | also involve vue/react as alternatives. Almost as ridiculous as
         | asking about using unity ui vs react.
         | 
         | 3. Flash was world class media design tool for animation and
         | production design. People were using it to create tv shows.
         | Figma is nowhere close in terms of alternatives like
         | illustrator, adobe ae, etc. So it's value as a runtime for
         | 'cool' effects would be very limited. Which is the only reason
         | to not use html/js because otherwise there's all kinds of small
         | usability issues (like things not scrolling right, or not
         | working with mobile). Figma's biggest value is it's
         | collaborative features which is really important for ui design.
         | I think devs (and other non-designers) overvalue Figma's
         | importance because of lack of famliarity. It's kind of like if
         | people thought you could use google docs or notion as an ide.
         | After all they're both text editors right, even if jetbrains or
         | vscode is better, it's maybe 10-20% better? But of course devs
         | know that they're world's apart, like comparing apples to
         | oranges.
         | 
         | [0] https://makepad.nl/makepad/examples/ironfish/src/index.html
        
           | Fraterkes wrote:
           | I do some graphics work and I wouldnt say that there is a
           | world of difference between the capabilities of Illustrator
           | and Figma. Photoshop is obviously a completely different
           | tool. Very textural digital painting of the kind that
           | photoshop excells at would be pretty tricky in a browser.
           | (Theres a webversion of Heavypaint now, but thats vector-
           | based of course.
        
         | fidotron wrote:
         | Figma definitely had a killer advantage with Evan Wallace
         | around. He might be known now for esbuild but he is a WebGL
         | demon of epic proportion.
        
           | inssein wrote:
           | Woah I had never connected the dots - I had used
           | https://github.com/evanw/glfx.js for a realtime photo editor
           | and then wrote https://github.com/inssein/jsfx to render the
           | same without WebGL for printing.
        
         | imslavko wrote:
         | It's worth noting that a lot of Figma's UI outside of the
         | canvas is React (panels, toolbars, menus, etc).
        
         | [deleted]
        
       | skhameneh wrote:
       | 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
        
         | imslavko wrote:
         | Absolutely! Evan and the early team laid a strong foundation
         | when Figma was ported to WASM + WebGL. It happened before my
         | time at Figma, but check out these earlier posts from Evan and
         | Jamie on the transition, perf testing, and graphs back from
         | 2017-2018:
         | 
         | https://www.figma.com/blog/webassembly-cut-figmas-load-time-...
         | https://www.figma.com/blog/figma-faster/
        
         | chrysoprace wrote:
         | Also the creator and maintainer of ESBuild!
        
       | mdtrooper wrote:
       | I want to write only: https://penpot.app/
        
       | permo-w wrote:
       | I used Figma recently on a decent laptop. I used it both in-
       | browser and within its desktop app. it was anything but fast.
       | lightning speed compared to Android studio, but slow compared to
       | anything else
        
       ___________________________________________________________________
       (page generated 2023-08-30 23:00 UTC)