I have a number of large pieces of precomputed data which I am considering putting into individual packages in order to load them (via DeclarePackage) and unload them (via Leonid Shifrin's PackageManipulations package) as needed. For what it's worth, I have some functions which will be defined on some objects using UpValues, and it is the UpValues which will be stored in the packages, one for each object.

I am wondering if performance or other issues occur, either in the kernel or the front end, when any of the following becomes large (hundreds or thousands):

1) $Packages,

2) The number of defined contexts,

3) $ContextPath.

Is it okay to create new contexts more-or-less at one's convenience, or does one need to be conservative, and if so, how?

Some other questions in which this situation might occur are here, here, and here (in Leonid Shifrin's answer.

  • 3
    $\begingroup$ I have not tried this with so many contexts, but I had once a discussion about this with one of the kernel developers who knows more about this, and he told me that there might be problems with scaling to a huge number of contexts, since the package system has not been originally designed with millions of simultaneously loaded packages / contexts in mind. Regardless of whether or not there will be problems with so many contexts, I would not keep many contexts on $ContextPath - normally this is never needed, and you can always group them so that at any given time, you only need a few. $\endgroup$ Aug 20, 2013 at 16:00
  • 1
    $\begingroup$ @Leonid Perhaps it is time to post that as an answer? $\endgroup$
    – Mr.Wizard
    May 15, 2015 at 6:05


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.