4

(NB: I could not find any good tags for this post. Please feel free to add better ones.)

Suppose that the file /some/path/dump.mx was generated during an earlier Mathematica session by evaluating an expression of the form

DumpSave["/some/path/dump.mx", ...]

...for some argument ... unknown to us.

Q: How can I find out which variables were set (or re-set) as a result of evaluating

Get["/some/path/dump.mx"];

...in my current Mathematica session?

kjo
  • 11,717
  • 1
  • 30
  • 89
  • 1
    How about https://mathematica.stackexchange.com/q/25027/5478? – Kuba Apr 30 '17 at 18:56
  • 1
    Not an answer, but you can also Export to the .mx format. If you use this method, then only the data will be saved, but any definitions. I much prefer this way. I can simply re-Import and assign to whatever variable name I prefer. If I want to save several pieces of data, and even give them names, then I use an association (or rule list in earlier versions). – Szabolcs Apr 30 '17 at 21:53
  • @Szabolcs: Export/Import does seem like the way to go. Thanks! – kjo May 01 '17 at 00:10
  • 2
    Possible duplicate – xslittlegrass May 01 '17 at 01:21

2 Answers2

4

Short summary

In your current Mathematica session, you can easily track creation of new symbols. There is however no simple way to track updating of symbols. As a workaround you can start a fresh kernel, load MX file there and track new symbols. This may give you some idea how given MX file will affect your current Mathematica session.

Methods to track new symbols defined by MX file can be found in the following question:

DumpSave for the forgetful

Update: I have moved some part of my answer from here to DumpSave for the forgetful, because that question is considered canonical.

Ray Shadow
  • 7,816
  • 1
  • 16
  • 44
  • you might want to mention that by using Off[General::stop] you can show all messages for case 2, which probably makes that approach much more valuable... – Albert Retey May 02 '17 at 08:13
  • @AlbertRetey Thank you! I have included this hint into the answer. – Ray Shadow May 02 '17 at 21:42
  • I marked this question as a duplicate but I see that you have since extended your answer. Do you feel that my action was incorrect? If this question is different from the other one can you edit it to make that more clear? If it is not what do you think of merging this question into that one which will move your answer to that question? – Mr.Wizard May 21 '17 at 19:33
  • @Mr.Wizard Sorry, I have noticed the duplicate notice only after I finished updating. I think it is a good idea to merge these questions. I will need to change some sentences after the merge is complete. – Ray Shadow May 21 '17 at 20:27
  • I'll come back to this tomorrow. A merge is irreversible so it must be approached with care. Nevertheless I favor having all answers in one place when it is truly applicable. – Mr.Wizard May 21 '17 at 20:46
  • @Mr.Wizard I have moved/rewritten the relevant part of this answer into a full answer for DumpSave for the forgetful. – Ray Shadow May 21 '17 at 23:31
3

This answer doesn't help you with past uses of DumpSave to store variables, but rather it offers an alternative. One obvious way to store a variable to be retrieved later is to use Put, as in:

m = RandomReal[1, {1000,1000}];

Put[m, "matrix.m"]; //AbsoluteTiming

stored = Get["matrix.m"]; //AbsoluteTiming

m === stored

{2.22504, Null}

{1.40961, Null}

True

As the timing shows, this method is rather slow. It also has an issue where some objects change when run through this Put/Get round trip. An alternative that I like is to define new functions, PutMX and GetMX (note that this can be made more robust by using a package):

PutMX[expr_, file_] := Block[{res=expr}, DumpSave[file, res]]
GetMX[file_] := Block[{res}, Get[file]; res]

As you can see, PutMX and GetMX use DumpSave under the hood, but in such a way that they mimic Put and Get. As an example:

PutMX[m, "matrix.mx"]; //AbsoluteTiming

stored = GetMX["matrix.mx"]; //AbsoluteTiming

m === stored

{0.015008, Null}

{0.005111, Null}

True

There have been some earlier suggestions to use Export[file, expr, "MX"] and Import[file] instead, but this approach is quite a bit slower, due to overhead in the Import/Export framework. For instance:

Export["matrix2.mx", m, "MX"]; //AbsoluteTiming

stored = Import["matrix2.mx"]; //AbsoluteTiming

m === stored

{0.07974, Null}

{0.055974, Null}

True

As you can see, PutMX/GetMX are quite a bit faster.

Carl Woll
  • 130,679
  • 6
  • 243
  • 355
  • 1
    The problem is that files saved with PutMX will only be compatible with GetMX but not Import. So I looked up what Import/Export do with MX. They use the same method that you show here: assign to a symbol and DumpSave, but they also wrap the expression with HoldComplete. The symbol used is System`Private`ConvertersPrivateDumpSymbol. If you also use this symbol instead of res (and wrap with HoldComplete), you could make PutMX compatible with Import. – Szabolcs May 01 '17 at 08:47
  • 1
    What is disappointing is that Import/Export do not use Block. Instead, Export just sets a variable and leaves it like that to consume memory ... it gets cleared only when Import is used. – Szabolcs May 01 '17 at 08:48
  • 1
    @Szabolcs Indeed after Export in MX, the symbol System`Private`ConvertersPrivateDumpSymbol retains a copy of the exported variable in memory. This should probably be reported. – Ray Shadow May 01 '17 at 09:01
  • @Shadowray OK, I reported it. I do not know if it will get fixed because it is such a minor issue. – Szabolcs May 01 '17 at 09:28
  • Thank you @Szabolcs. Leaks like this are hard to notice but they can sometimes lead to unexpected memory and performance issues. – Ray Shadow May 01 '17 at 09:38