You might not aware that jmf requires the whole memory map file to be load into memory. For example you got an 4GB file and the computer got only 4GB of RAM, it will begin to swap and you will then have time for a coffee or even a holiday.
Чтв, 14 Окт 2010, Martin Pelletier писал(а): > Thanks Alex. I agree with all of your PROS. Even CON 1 isn't that big > a deal. > > What I'm dealing with is a very large of J mapped files. If I could > fragment it easily, I would. > > The biggest file I have is an array that grows by 86400 entries daily. > That's right, one for every second of every day. That means about > 31,536,000 numbers a year. You get the picture... I really wish the > original programmers had at least read the page that said it was > untested. It's pretty clear that I need this broken down by day. But > there's a lot of code to arrange to get there. > > In my current project, most of the data crunching is done by J, C# > serves as a front end and sends commands rather than actual data, which > is read by J and not sent to C# so much. I was trying to wrap the J64 > Interop to allow easier use with various data types (avoid manual > casting, etc), but obviously not to transport such large datasets. > Coming across this limitation made me want to share it with the community. > > Has the point become moot now? > > Martin Pelletier > > On 2010-10-14 19:14, Alexander Rufon wrote: > [---=| TOFU protection by t-prot: 19 lines snipped |=---] -- regards, ==================================================== GPG key 1024D/4434BAB3 2008-08-24 gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3 ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
