Thank you Michael...
Michael Goffioul wrote:
> On Sun, Jan 17, 2010 at 8:39 PM, Philip Nienhuis <[email protected]>
> wrote:
>>> You might want to try playing with the JVM arguments, especially
>>> the memory controlling arguments. The java package reads arguments
>>> from a file java.opts located in the same directory as javaclasspath.m.
>>>
>>> Michael.
>>>
>> On my system (Win XP using the octave-3.2.3 MingW binary) that subdir is:
>> "C:\Programs\Octave\3.2.3_gcc4.4.0\share\octave\packages\java-1.2.6"
>> but there's no java.opts there.
>>
>> Nor in:
>> "C:\Programs\Octave\3.2.3_gcc4.4.0\libexec\octave\packages\java-1.2.6\i686-pc-mingw32-api-v37"
>>
>> Nor is there a java.opts in the java-1.2.6.tar.gz package.
>>
>> Searching the hard disk: no java.opts :-(
>>
>> (Hmmmm but I do have a vague reminiscence of having once seen a file called
>> "java.opts" somewhere ..... it does ring a bell.)
>>
>> Do you have an example file, or did I overlook something? Or is it left out
>> on Windows systems?
>> I'll have a look on my Linux system, but I must reboot for that so that'll
>> be later tonight.
>
> Sorry, I wasn't clear enough. The java package has the ability to read
> additional options to pass to the JVM on initialization. Those options
> are read from the java.opts file, if it exists. You can see the default
> options used here [1] around line 407. The java.opts file syntax is the
> same as Matlab, one option per line. Refer to the java documentation
> for the possible options (see for instance [2]).
>
> Michael.
>
>
> [1]
> http://octave.svn.sourceforge.net/viewvc/octave/trunk/octave-forge/extra/java/src/__java__.cc?revision=6098&view=markup
> [2] http://java.sun.com/j2se/1.5.0/docs/tooldocs/windows/java.html
... that helped.
I've put a file "java.opts" containing just the lines
-Xms16m
-Xmx512m
in
C:\Programs\Octave\3.2.3_gcc4.4.0\share\octave\packages\java-1.2.6
Using those settings (memory pool start size = 16 MB, max size = 512 MB)
I now could write a 300x1024 double array to an OOXML or ODS file,
followed by adding the same array below the first one without problems
(to get altogether 600x1024 spreadsheet cells filled).
It fitted with little left as -after processing the spreadsheets- executing
rt = java_invoke ('java.lang.Runtime', 'getRuntime');
rt.maxMemory().doubleValue() / 1024 / 1024
yielded
ans = 508.06
rt.maxMemory().doubleValue() / 1024 / 1024
ans = 51.797
(i.e. only 52 MB free memory left).
I'd say those two figures should add up to 512 rather than 560 but
that's just me :-)
All this indicates that writing spreadsheets through java is not
extremely memory-efficient; arrays or spreadsheets with existing data
sizes of the order of 5.10^5 cells seem to be the maximum size that can
be processed by the java-based scripts.
I suppose mat-files offer a better solution for saving larger array sizes.
Thanks,
Philip
------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
Octave-dev mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/octave-dev
