Consider this sequence of commands:
foo10 = RandomReal[{0, 1}, {5000, 10}];
Export["D:\\Dropper\\Dropbox\\footest.csv", foo10] // AbsoluteTiming
{0.898086, "D:\\Dropper\\Dropbox\\footest.csv"}
foo100 = RandomReal[{0, 1}, {5000, 100}];
Export["D:\\Dropper\\Dropbox\\footest.csv", foo100] // AbsoluteTiming
{7.428425, "D:\\Dropper\\Dropbox\\footest.csv"}
foo1000 = RandomReal[{0, 1}, {5000, 1000}];
Export["D:\\Dropper\\Dropbox\\footest.csv", foo1000] // AbsoluteTiming
{65.063763, "D:\\Dropper\\Dropbox\\footest.csv"}
Two (at least) things leap to mind:
The first is that the performance is truly atrocious (this is on a very fast machine, on a local file system.
The second is that the times grow sublinearly in the size of the input, which indicates a whole'nother kind of weirdness.
Does anyone understand what is going on, and if there is a reasonable workaround?
EDIT Following up on @belisarius' suggestion, here are the Timing[] results for the three commands:
0.671875 4.65250 47.968750
From which we see that both the OS interaction and the internal computation are ridiculously slow. But it gets worse. In the middle of doing this experiment, when I was running the commands exactly as above with AbsoluteTiming[]
replaced by Timing[]
, between the first and the second command Mathematica informed me that it could not do the Export[]
because the "footest.csv" file was already open (which means that it did not do the necessary fclose()
, or whatever Windows calls it, of course changing the file name fixed it.
For posterity, this is Mathematica 10.0.1 on Windows 8.1
ANOTHER EDIT Just for completeness: I tried the same experiment with ".dat" instead of ".csv", and the results were essentially identical (including the fclose()
bug). Which makes it surprising (though gratifying) that there is an actual format that works quickly, as pointed out by @Jens.