You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've noticed that utilizing the DFX_MOC_PATH=moc-wrapper indirection to select a particular moc binary, though convenient, can drastically slow down builds using dfx.
The problem is that dfx actually invokes moc repeatedly to determine the dependencies of a motoko project, not just once. On my machine, calling moc indirectly through moc-wrapper is about 50x slower than calling a particular moc binary.
Once we've determined which binary to use, the overhead can be avoided by re-defining DFX_MOC_PATH accordingly so there is a manual workaround, but it causes friction.
@ZenVoich can you think of any way to fix this? Is there a clean and safe way to cache the result?
The text was updated successfully, but these errors were encountered:
I've noticed that utilizing the
DFX_MOC_PATH=moc-wrapper
indirection to select a particular moc binary, though convenient, can drastically slow down builds using dfx.The problem is that
dfx
actually invokesmoc
repeatedly to determine the dependencies of a motoko project, not just once. On my machine, callingmoc
indirectly throughmoc-wrapper
is about 50x slower than calling a particular moc binary.See dfinity/sdk#3699 for an example.
Once we've determined which binary to use, the overhead can be avoided by re-defining DFX_MOC_PATH accordingly so there is a manual workaround, but it causes friction.
@ZenVoich can you think of any way to fix this? Is there a clean and safe way to cache the result?
The text was updated successfully, but these errors were encountered: