-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Performance thread #149
Comments
Hi @jordisala1991 and @Cenadros, I will have soon some days to contribute to your plugin and I'm definitely interested by your thoughts on the following. The final goalThe french government's design system (named DSFR) is currently only available and maintained on Figma (https://www.figma.com/@gouvfr and https://github.com/GouvernementFR/dsfr) and we are interested by the open source approach of Penpot. The most effective for us would be to keep our design system designers only working on Figma (since they do it right now, and to not duplicate the hard work of maintaining multiple platforms). But we expect a result similar enough into Penpot (which implies documents synchronization), so our agents can use it. Context and roadmapThe initial plan I had was:
As stated before I had some performance issues:
I see 2 possible paths to follow: A. Initial planI keep the initial plan and can help you on improving the performance of exporting. But I have no guarantee in a short time to help on improving Penpot performance so it does not crash when it has too many components. So after those days there is a risk our design system would be on Penpot but not usable until the core team find tricks to improve Penpot performance (which were announced during the last live), or until the plugin optimize enough current duplicates (but not sure 100% it would solve issues since the original document is huge). Or maybe it would be usable but only to powerful computers? (mine is MBP 2020) B. API Alternative planOtherwise, have a third binary to make the export and the import by using REST APIs from Figma and Penpot. The global idea would be:
Pros I see:
Cons:
Did you already think about the (B) path? Do you think it can make a difference in term of performance/usability? And if the benefit would be enough compared to the (A)? Or is it a loss of time and it's better to full focus on (A)? Thank you, By the way: do you have a specific Discord or so for discussions about this plugin? |
Hi,
Following up on my message on performance issues both for exporting and importing https://community.penpot.app/t/figma-to-penpot-export-plugin/5554/7?u=sneko I make this thread to not flood the official forum announcement.
I had a look at browsing Figma nodes and it seems what justifies having
async
on all functions liketransformChildren / translateChildren / transformSceneNode / transformGroupNode / ...
is due to what's insidetransformInstanceNode
in case of a remote component (bothawait node.getMainComponentAsync()
andawait registerExternalComponents(mainComponent)
).I'm not familiar with those, but if they indeed do remote calls, since all the browsing is done with chained
await
infor
loops, it will act as synchronous operations. I'm wondering if doing things likePromise.all()
instead would help when "real async functions" are called.[EDIT while writing this I saw your message on the forum] It seems you face issues when parallelizing those. Juste some ideas instead of using a
Promise.all
that would make Figma crashes:async
(using for exampleeachOfLimit()
, cf. https://www.npmjs.com/package/async). Since there is a lot of level of abstraction, it's needed to define where to apply this // ? Only on "page layer" and sub-layers with a Promise.all by default?window.performance.memory
(still hard to know about the computer capacity but it may help?)N-4
is already ongoing 3 times (but blocking due to network requests), the logic ofeachOfLimit
may not help since scoped to where it's called. In this case, adjust with a share instance? Or a shared semaphore/mutex?(I will keep you updated if at work I have free time to contribute to the plugin, will be easier than just trying to say "try this or this" (sorry for that))
cc @Cenadros
EDIT2: additional notes:
RemoteComponentsLibrary
, also parallelize?Map
insideRemoteComponentsLibrary / ComponentLibrary
instead of an object? Maybe remove from theMap
once a specific iteration has been fully processed (not sure if this one can be huge)? The latter could apply everytime it's a new object created (not a reference to an internal from Figma).EDIT3: Allow exporting specific pages? It would allow people to do chunks (an export for a huge page, and another for the rest), so the export process works and that the import does not make Penpot crashing (it breaks the ideal, but makes things usable).
EDIT4: Did you think about using the Figma REST API instead of the FIgma Plugin API? It would avoid having a Figma instance running, but not sure everything is possible (despite seeing endpoints to get nodes...). The downside is it's less accessible for lambda people (due to access token to enter, using a binary or having it hosted somewhere else).
EDIT5: Just saw there is a
download report
when Penpot crashes when opening an import (not really seeable in dark mode). It's always the same error:I should dig into it.
The text was updated successfully, but these errors were encountered: