So your contention is that the instance swap and text properties are the things that are causing the memory to be much larger, and not the fact that there are tons of hidden layers for all of the other boolean props? Just want to make sure that is the basics of the answer. It just didn’t look like that was the case. it looked like it was the fact that there were a bunch of hidden layers on one and not on the other.
My team is having similar issues and I’m getting a bit worried. We’re heavily using booleans and memory usage has increased by quite a lot. So @Sula_Yang we’re saying if we limit instance swap and text properties we can reduce memory usage?
1 Like
I did another test recently and it still remains that when I have a ton of variants it reduced the file size a ton. I put 6k fields on a page and the one with all variants was 5.6% memory and the one with only a few variants was 12% memory for the same number of fields and types of fields. This hasn’t been addressed, so for large designs, our system will have to have one of those sets of components where it just has a ton of variants for now. Hope this helps Alissa.
@Corey_O_Brien - I’m interested in your testing methodology. I’ve had the same question about how best to implement components with conditionally-displayed layers. My experience has been that when there is a large number of conditional layers, using boolean properties consumes more memory than using variants, but I haven’t done any quantitative testing.
In some of my use cases (e.g., tables), this could be addressed by the ability to include an arbitrary number of instances of another component. (See my post: Allow arbitrary/dynamic number of nested instances)
1 Like
Oh man, this stinks. I guess we will have to recreate some components as it is a serious issue.
I created components for an input field. I then created a simple 5 field form with a few different types. I replicated this a bunch of times until I had around 6k fields on a page. I used 7 different sets of components with varying amounts of properties vs variants. The smallest memory usage page was the one with all variants. The worst was the one with the most properties. The only conclusion I can make from this is that the hidden layers from the properties takes up memory when rendering the page.
My situation was extreme in that I added 6k fields on a single page, but I was trying to make sure I could see the difference in the memory. Also, this was just the input field component. We will have much more complicated components, like tables or cards, that would have a lot more hidden layers.
I love the concept of the properties for making strong, yet easy to maintain components, but at my company, we do often have files with a thousand web pages and those thousand pages might have 15 components on each. We have some very slow Figma files a bunch, and do have to split up files to keep them running sometimes, so the more I can do at the component side of things the better it will be even if the component itself is hard to maintain.
I have the same question; could you please verify this, @Sula_Yang
? After this thread, I understood that boolean takes up less space. However, in the case of this list, I can’t imagine every left and right item to be boolean because it would get messy.
Another option, which is also less elegant, is to use instance swap for less-used items. Now, I wonder what actually takes up more space. This component is also used by non-designers, so it should be clear for them what to use.
@Corey_O_Brien what is interesting for me here, is whether Figma loads instances with hidden fields only when the page with them are opened.
Meaning if we have a library of components with boolean properties and we use the components in our designs on some page - those instances will be loaded only on the page where we are currently working.
Whereas the variants are being loaded in global memory of Figma, because of we need to have them at hand at all times via assets page.
So the solution here is to split designs into more pages so that their instances get lazy loaded.
But it is only assumption from me, I’m not sure how Figma handles the memory and currently I’m also facing the issues, Figma got really slow because of lots of nesting in my components… I’ve decided to rebuild design system with reduction of nesting and with migration from variants to boolean properties. I will let everyone know when I’m done, how it goes.
Also @Sula_Yang can you confirm whether my assumptions are correct or not?
The way I see it is that it is actually tricky how Figma uses memory. If you don’t visit a page, it doesn’t seem to take up memory much. Once you do, it draws the components on the page and then that page takes up more memory than it did originally.
I don’t know if you are correct that a component with variants takes up more memory because it is loaded into memory globally. I haven’t tested that out. Not sure why a variant would take up more than a boolean would in that regard.
What I do know is that the more layers that are present on the left-nav, the larger the memory usage is and because variants don’t show up as multiple layers and only bring in the layers in the variant you select, it takes up less memory. Even if the base component was loaded with all of the extra duplicate layers from the variants, it would still be more memory efficient than having each instance where you use that component containing the extra layers IMO.
1 Like
Just found this thread because we’re struggling a lot with Figma performance lately.
When setting up components over the last year, I strictly went for the Base component approach for easier maintainability and now this seems to boomerang performance-wise. Yes, we do have tons of hidden layers. This is so annoying and I hope Figma can do sth about how it handles memory.
I use a fast internet connection, Desktop app and a powerful M2 MacBook Pro.