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
The mi interpreter, and to a lesser extent also the boot interpreter, uses a significant amount of memory during the bootstrapping. Running the first bootstrapping stage with boot leads to a peak memory usage of around 1.1 GB while using the mi interpreter (as in mi eval src/main/mi-lite.mc -- 0 src/main/mi-lite.mc mi-lite) memory usage peaks at 4.4 GB. This gets even worse after #697.
I've found that one reason for this is the filename part of the info fields. I hacked together a version of the compiler where the filename is converted to a SID rather than a String (so an integer rather than a string encoding the full path of the file each AST node originates from). This led to worse runtime performance (as I said, it is a hacked-together solution), but peak memory usage drops to 0.7 GB for boot and 1.7 GB for mi eval. I think this suggests that we need to consider how we represent the filenames in our info-fields. You can find the hacked-together code at https://github.com/larshum/miking/tree/sid-hack.
The text was updated successfully, but these errors were encountered:
The
mi
interpreter, and to a lesser extent also theboot
interpreter, uses a significant amount of memory during the bootstrapping. Running the first bootstrapping stage withboot
leads to a peak memory usage of around 1.1 GB while using themi
interpreter (as inmi eval src/main/mi-lite.mc -- 0 src/main/mi-lite.mc mi-lite
) memory usage peaks at 4.4 GB. This gets even worse after #697.I've found that one reason for this is the
filename
part of the info fields. I hacked together a version of the compiler where thefilename
is converted to aSID
rather than aString
(so an integer rather than a string encoding the full path of the file each AST node originates from). This led to worse runtime performance (as I said, it is a hacked-together solution), but peak memory usage drops to 0.7 GB forboot
and 1.7 GB formi eval
. I think this suggests that we need to consider how we represent the filenames in our info-fields. You can find the hacked-together code at https://github.com/larshum/miking/tree/sid-hack.The text was updated successfully, but these errors were encountered: