I frequently convert multi-frame 16-bit TIFFs into raw binary movies.
I use fwrite in a loop, with a typical frame size 512x512, 1000-10,000
frames at a time. On every "old" 32-bit Win XP machine I've tried,
fwriting a 1,000-frame 512x512 16 bit movie (512 Mb raw file size)
takes ~30 sec (standard 7200 rpm hard drives etc). On a 64-bit Win 7
top of the line laptop, 64-bit matlab, fresh Win 7 installation, the
same fwrite is 5x slower ~150 seconds. The only way I could match the
XP fwrite speed was to change matlab thread priority in W7 to real
time. This causes Java crashes every now and then.The XP thread
priority was always default "normal". with no tweaking required. Is
there anything I can do about W7 settings, w/o compromising its
stability, to make W7 acceptable for data processing in matlab? I
could care less about "Windows 7 experience". I guess data processing
it's not what Win 7 was designed for...

runcyclexcski <runcyclexcski@gmail.com> wrote in message <a4b03154-d0f1-4969-b5df-966553ed6748@b25g2000vbz.googlegroups.com>...
> I frequently convert multi-frame 16-bit TIFFs into raw binary movies.
> I use fwrite in a loop, with a typical frame size 512x512, 1000-10,000
> frames at a time. On every "old" 32-bit Win XP machine I've tried,
> fwriting a 1,000-frame 512x512 16 bit movie (512 Mb raw file size)
> takes ~30 sec (standard 7200 rpm hard drives etc). On a 64-bit Win 7
> top of the line laptop, 64-bit matlab, fresh Win 7 installation, the
> same fwrite is 5x slower ~150 seconds. The only way I could match the
> XP fwrite speed was to change matlab thread priority in W7 to real
> time. This causes Java crashes every now and then.The XP thread
> priority was always default "normal". with no tweaking required. Is
> there anything I can do about W7 settings, w/o compromising its
> stability, to make W7 acceptable for data processing in matlab? I
> could care less about "Windows 7 experience". I guess data processing
> it's not what Win 7 was designed for...

My guess is that Java is crashing because the garbage collecter isn't getting an opportunity to clear the heap.  Perhaps add an explicit call to java.lang.Runtime.gc() if the ratio of (java.lang.Runtime.freeMemory() + java.lang.Runtime.maxMemory() - java.lang.Runtime.availMemory()) to java.lang.Runtime.maxMemory() isn't large enough within your loop (say, greater than 10%).  You could also try increasing the memory allocated to the Java VM Heap using File->Preferences:General->Java Heap Memory.  Let us know if this fixes your issue.

On Nov 18, 12:31=A0pm, "Jeff Gullett" <Jeffrey.Gull...@ngc.com> wrote:
> runcyclexcski <runcyclexc...@gmail.com> wrote in message <a4b03154-d0f1-4=
969-b5df-966553ed6...@b25g2000vbz.googlegroups.com>...
> > I frequently convert multi-frame 16-bit TIFFs into raw binary movies.
> > I use fwrite in a loop, with a typical frame size 512x512, 1000-10,000
> > frames at a time. On every "old" 32-bit Win XP machine I've tried,
> > fwriting a 1,000-frame 512x512 16 bit movie (512 Mb raw file size)
> > takes ~30 sec (standard 7200 rpm hard drives etc). On a 64-bit Win 7
> > top of the line laptop, 64-bit matlab, fresh Win 7 installation, the
> > same fwrite is 5x slower ~150 seconds. The only way I could match the
> > XP fwrite speed was to change matlab thread priority in W7 to real
> > time. This causes Java crashes every now and then.The XP thread
> > priority was always default "normal". with no tweaking required. Is
> > there anything I can do about W7 settings, w/o compromising its
> > stability, to make W7 acceptable for data processing in matlab? I
> > could care less about "Windows 7 experience". I guess data processing
> > it's not what Win 7 was designed for...
>
> My guess is that Java is crashing because the garbage collecter isn't get=
ting an opportunity to clear the heap. =A0Perhaps add an explicit call to j=
ava.lang.Runtime.gc() if the ratio of (java.lang.Runtime.freeMemory() + jav=
a.lang.Runtime.maxMemory() - java.lang.Runtime.availMemory()) to java.lang.=
Runtime.maxMemory() isn't large enough within your loop (say, greater than =
10%). =A0You could also try increasing the memory allocated to the Java VM =
Heap using File->Preferences:General->Java Heap Memory. =A0Let us know if t=
his fixes your issue.

Jeff, thanks a lot for the response; the heap issue makes sense, I
will include those calls in my loop.

This is probably a W7 question, but do you happen to know if there is
anything about how W7 allocates resources and scheduled HD writing
activity that affects Java or ML priority? I have disabled the most
notorious windows 7 "experience" services but it did not have any
effect, only explicit thread priority set makes ML tick at the desired
speed.

Just wonder if you tried the 32-bit ML under 64-bit window. In some circumstances, there is a significant slowing down of data transfer if you run 64 bit version.

Bruno

On Nov 18, 1:52=A0pm, "Bruno Luong" <b.lu...@fogale.findmycountry>
wrote:
> Just wonder if you tried the 32-bit ML under 64-bit window. In some circu=
mstances, there is a significant slowing down of data transfer if you run 6=
4 bit version.
>
> Bruno

I am running 64 bit ML under 64 bit Win 7. Haven't tried 32 bit ML
under 64 bit WIn7. WIll try.

Also, after a day of work in 64-bit ML, I have found that the GUI in
the 64 bit ML  (clicking objects, zooming in, zooming out figures,
etc) is much slower than under 32 bit ML+XP. This is with the "real
time" setting of the process thread. It was slow to a point that have
given up on the 64 bit ML entirely and went back to the 32 bit ML+Win
XP on my old desktop, essentially converting my brand new Thinkpad
into a paperweight for now. I will probably reinstall 32 bit XP on it.