Live data from Hacker News

Keeping Figma Fast: perf-testing the WASM editor

figma.com

91–99 of 99 posts

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

#91

Earlier quoted context omitted.

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.

We omitted the details for the sake of brevity (the article is already really long), but we run agents on the test devices and plug them into CI. Agents allow remote access for servicing remotely, and that's enough most of the time.

For things like system updates and taking care of the hardware - we do it manually today. The fleet is still small, so it is manageable but in the future we would like to consider a vendor, if we can find one.

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

#92

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 should not be the case even on a single CPU machines that run interactive jobs. This is a shoddy process scheduling work.

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

#93
post #89
post #74

Earlier quoted context omitted.

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.

All the other apps are fine. It’s whatever browser is trying to load Figma that freezes.

I’ve had a mouse cursor move slowly when doing some tasks in Chrome. And all other apps barely reacting. Still a mystery to me. I hope that was not a sign of some backdoor being installed through a Chrome vulnerability.

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

#94

Earlier quoted context omitted.

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.

We omitted the details for the sake of brevity (the article is already really long), but we run agents on the test devices and plug them into CI. Agents allow remote access for servicing remotely, and that's enough most of the time. For things like system updates and taking care of the hardware - we do it manually today. The fleet is still small, so it is manageable but in the future we would like to consider a vendo…

Thanks!

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

#95
post #44

Earlier quoted context omitted.

Requiring figma at a job should be a human rights violation :). I'm off the grid and whenever I use figma it drains my batteries with a high CPU load. I have to be careful to open it during the dead winter, if I leave it open I could drain my entire 5kw setup. If I throttle my CPU, it's totally unusable. Hopefully I can get a more efficent setup (currently an old 2400GE minipc). Usually I take a screen snapshot becau…

When I read stuff like this I can never tell if it is someone making a joke or just extreme complaining. The computer you mentioned comes with a 65 watt AC/DC converter which should last 77 hours minimum on a 5kw battery. Then there is the nonsense about blaming a web page for not having enough power after choosing to do a tech job while living off a battery.

didn't want to hijack the thread about my personal setup, but that's almost about right amount of power usage I aim at entirely, about 120-200 watts per hour: but there are other things plugged in besides my desktop like ... my entire house. Lights, freezer, monitor, radio, DC adapters, starlink. Another 30-50w is just insane to run Figma. My freezer chest uses less and at least I can grab a steak.

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

#96

Earlier quoted context omitted.

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 l…

Last time I checked, Penpot was creating/destroying actual SVG elements in the dom. I get the sentiment of wanting to use open technology, but for the average user Figma's "copy as svg" is probably open enough. And switching to canvas based rendering would probably improve performance a lot.

Imagining a future where Penpot gets Blender-level resources and implements an SVG VM in WASM that renders to WebGL.

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

#97
post #24

Earlier quoted context omitted.

+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.

It's amazing what we lost moving from desktop to retrograde world of the web. I wonder what's next in the indirection game?

If you think the web is bad, check out what Apple is planning for their AR headset. The future is apparently a platform so locked down that as a developer you can't directly access the primary input device (eye tracking) at all, you can only pick from a palette of predefined UI behaviors. You can't have access to the cameras to do any custom computer vision; hope you like the primitives Apple deigns to provide to you. And you can't even write your own shaders to render custom graphics; you'll have a preset material model and you'll like it. https://twitter.com/Tojiro/status/1667028702734209025

Honestly I guess it's similar in capabilities to the early web before the introduction of JavaScript, where all custom code had to run on the server. Maybe Apple's plan is to increase capabilities over time the same way the web did. I kind of don't think so, though.

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

#98
post #24

Earlier quoted context omitted.

+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.

It's amazing what we lost moving from desktop to retrograde world of the web. I wonder what's next in the indirection game?

If you put a shareable state into desktop apps it could swing the other way. I'm not a designer but to just put a url to a mock-up is amazing.

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

#99

Earlier quoted context omitted.

You should get a mac laptop, you can run figma all day without even needing to plug in the laptop to charge.

I hope this is satire. The glaring problem with software performance nowadays is corporations having convinced consumers to work around their slow and terrible software by throwing more hardware at it and buying multi-thousand dollar computers.

Software companies must be a non-trivial driver of e-waste.
Post reply on HN