For efficiency reasons I prefer to use DumpSave instead of Save.

For ease of access I prefer to save symbols in DumpSaved files inside Global` context.

But when my code evolved and I moved it inside packages I found a lot of problems to read symbols from those DumpSaved files so that read & write process

  • allows for use saved variables inside my package (and its context)
  • does not affect variables in Global`
  • When user loads the file directly with Get, bypassing my package (and perhaps not even loading it), the symbol is available in Global` context for him or her
  • symbol name is not hard-coded into function (but of course it must hard-coded into the file itself :-( )

Simply put: I want to use DumpSave & Get the way I use Export & Import, but with efficiency and flexibility benefits.

I come up with the following code, but it still messes the Global context and has the symbol name hardcoded (Global`myglobalname):

SaveMySymbol[object_,path_String]:= Block[{},
   OwnValues[Global`myglobalname] = HoldPattern[Global`myglobalname] :> object;
    path<>".mx", Global`myglobalname]];

LoadMySymbol[path_String]:= Block[{strfullpath},
  strfullpath = path<>".mx";
  If[FileExistsQ[strfullpath], Get[strfullpath]; Global`myglobalname,

I guess the problem with messing the Global` context can be avoided by caching the maybe existing definition of Global`myglobalname symbol and returning it back after Get. But the code look already awfully complex (it took me a full day to figure out the trick with OwnValues) and I suspect that there must be an easy way... Well, so far there always was one with Mathematica...

  • $\begingroup$ Welcome to Mathematica.SE. Your question alludes to and then disallows some possible solutions. Would you consider using a context other than Global` for example? $\endgroup$ – Mr.Wizard Mar 22 '12 at 22:53
  • $\begingroup$ If possible not. With different symbols' context the answer would be trivial, but I prefer to lay it in Global` for ease of debugging. I've updated the problem statement to avoid confusion. $\endgroup$ – Adam Ryczkowski Mar 22 '12 at 23:03
  • $\begingroup$ Have you tested and ruled out all options described here? $\endgroup$ – Mr.Wizard Mar 22 '12 at 23:12
  • $\begingroup$ All ruled out. I specifically need DumpSave. It is a huge amount of data, and it takes over 200MB and a few minutes to write it in this optimizied format. $\endgroup$ – Adam Ryczkowski Mar 22 '12 at 23:15
  • $\begingroup$ Is it the saving or loading that you find slow? Also, have you seen this yet? $\endgroup$ – Mr.Wizard Mar 22 '12 at 23:25

To show how this is possible:

Simply put: I want to use DumpSave & Get the way I use Export & Import, but with efficiency and flexibility benefits.

You can simply use Import and Export. They do support the same format that DumpSave uses, and they give you the same performance. But they don't save symbol names.

Export["data.mx", data, "MX"]

data = Import["data.mx"]

MX files are not portable between architectures though, so you may consider using Compressed strings, as described here. This is several times slower, but it's still quite fast compared to any other alternative and it's portable.

If you ever need to save InterpolatingFunctions, please be aware of this problem.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.