old-code memory hog?

Everything related to our flagship word processor.
Post Reply
MyronGochnauer
Posts: 8
Joined: 2009-08-12 02:59:46

old-code memory hog?

Post by MyronGochnauer »

Yesterday I converted a one-page WordPerfect document. I did what needed to be done, and closed the file. Nisus Writer Pro was still running, but no other documents were open.

This morning I was using the Activity Monitor to check memory usage by a program that seemed to be malfunctioning, and I noticed a process called "soffice.bin". It was using 0.7% of the CPU time and 122.89 MB of real memory (and 895 MB of virtual memory!). It was also a Power PC process rather than Intel. It was called by Nisus Writer, so I assume it is part of the conversion system.

Coming from the days when 128K memory was huge, and the best programs were written in assembler, 122 MB is a hair-raising amount of memory to be hanging onto when not in use. And while 0.7% CPU load may seem small, if all of the programs and processes I used were this demanding "just-in-case", the total load would make a real-world difference.

So: Why is this still PPC instead of "universal" code?
Why doesn't it unload itself when it is not being used?
and, why does it need to sip away at the CPU instead of just waiting until it is called?

Then whole thing seems wasteful and sloppy... unless it normally does not operate this way.

I suspect that the conversion coding is farmed out to someone else. Perhaps it's time to crack the whip and demand better coding.
ptram
Posts: 280
Joined: 2007-10-21 14:59:09

Re: old-code memory hog?

Post by ptram »

It sounds like some OpenOffice code. If I remember correctly, conversion code was taken from there.
User avatar
martin
Official Nisus Person
Posts: 5227
Joined: 2002-07-11 17:14:10
Location: San Diego, CA
Contact:

Re: old-code memory hog?

Post by martin »

ptram is correct, "soffice.bin" is our file importer, which is a stripped version of OpenOffice.
122 MB is a hair-raising amount of memory to be hanging onto when not in use
It's not insignificant, but personally I don't find it shocking. These days applications link to numerous large umbrella frameworks that can load up a whole host of code/data. Besides, if the memory really isn't being used in the "soffice.bib" idle state, then it may just be memory that hasn't been swapped out by the virtual memory system.
MyronGochnauer wrote:Why is this still PPC instead of "universal" code?
The "soffice.bin" program is over 150MB on disk, so a universal version would be over 300MB. We thought that was too large.
Why doesn't it unload itself when it is not being used?
To make subsequent conversions faster. "sofffice.bin" can be sluggish to load. However, if you quit NWP then "soffice.bin" is also terminated.
why does it need to sip away at the CPU instead of just waiting until it is called?
This I can't answer offhand. Probably they're using some kind of event polling instead of letting OSX activate the process as events are received.
Post Reply