Posted: Wed Feb 16, 2005 4:35 am Post subject: curiosity about speed
I have a curiosity about the speed of neooffice:
I tryed to open a large calc file I use, with neooffice, openoffice x11 (for mac) and openoffice windows on a 2ghz machine.
neooffice takes 50 sec. to open it, the openoffice win and x11 around 30 sec.
After I start a macro on neooffice and openoffice x11: neooffice takes around 30 seconds to end the macro, openoffice x11 around 10 seconds.
So, I'd like to know what is 'slowing' the neooffice code on mac. It is not a memory problem, 'cause I have enought, is not a microprocessor problem, 'cause I see the OO x11 on my pb 1,33 is fast as the 2ghz win version of Oo.
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Wed Feb 16, 2005 9:20 am Post subject:
It very well may be the quartz font rendering. ATSUI is notoriously inefficient if you don't use it just right. Patrick's recently done some work to cache layouts which has improved speed for certain operations, particularly things like computing dialog layouts and selections. Hopefully that'll be the case.
Also when documents are opened on Neo we go through and construct the full menubar (I think). This is more of a need for the NMF so we can populate the native menubar. None of the other OOo's are doing this, and it wouldn't surprise me if I did something inefficient there myself.
Just out of interest, how much do you have there? And what else (if anything) was running at the same time as Neo/J?
I've noted before that Neo/J runs slower on my friend's 867MHz alubook with 640Mb of ram than on my 400MHz tibook with 1Gb of ram. And as soon as I have anything else big (like virtual pc) running on my tibook, Neo/J slows right down even when vpc is idle. So the amount of ram is also a key feature with speed.
Thank you ed for the answers. Sure for the macro issue I think the quartz is slowing down neooffice, cause the macro I used for the testing look for a free space in a banc form, scrolling down until it find one. So the scrolling is real slower that x11 version, probably for quartz.
Opening files, I don't know if this could be a menu case. I'll try to be more clear: some of my calc files are coming from staroffice. When I change staroffice-->openoffice on my old win machine, I saved in Oo calc format, and now, after the loading, Oo load the calc file and write in the bottom of the window 'adapt row height', and adapt row height for every sheet of Calc (204 sheet). I do not know why, this happen only using the Oo calc format. Anyway, using x11 this is quite fast, while neooffice is clear slow making this row change. But I do not think this could be a quartz or menu case. So I was wondering, if the 'adapt row' is a pure calc, why neooffice is more slow, if che codebase for calc is the same.
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Tue Feb 22, 2005 10:40 pm Post subject:
Hmm...with the macros involving scrolling is it possible to write it in such a way that doesn't do graphical scrolling? I would think that graphical scrolling only should be the problem, but there are a number of cases I've found that do actually call into ATSUI or other graphics calls even though they don't do anything on the screen (e.g. figuring out text metrics for the selection made by Find All)
Actually the scrolling macro is quite silly: it copies some datas from a sheet, write those to disk, jump to another sheet, and scroll down looking for an empy place to 'append' the saved data.
The scrolling takes more than 20 second in my pb 1,33 at maximum cpu speed. The same scrolling takes less than 2 seconds in openoffice for windows, on a 2ghz machine with 256 mb of ram (sigh), so I think it is a 'quartz' problem or similar.
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Thu Feb 24, 2005 12:37 am Post subject:
Some of that very well may be Quartz, but a bit part of it is that OOo's got a restricted world-view...it really relies on having a valid XOR in order to do its selection drawing. Quartz & Java 2D actually don't support XOR, so Patrick had to implement it himself in order to allow OOo to draw things correctly.
Comparing any platform to Windows will always be a losing effort with OOo, Mac, Linux, Solaris, or others. The underlying graphics layer abstraction was coded primarily by Windows programmers, so GDI is the closest match for it. We'll most likely need to maintain the XOR hackery until Microsoft decides to get rid of XOR in GDI (which probably won't happen anytime soon)
I undesrtand. Yesterday I was trying a macro I usually do, and it was more fast as usual. I ask myself why, when I see I was using the full screen mode. After some experiment I understand that my macro is quite fast until it need to scroll the window. If the macro is going outside the screen for read a cell content (for example), the speed decrease for the scrolling.
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Fri Apr 08, 2005 8:36 am Post subject:
I don't know offhand if there's a way to query the cell contents without adjusting the selection from a macro...I think it's the selection moving to the new cell that forces the scroll. I know there's no way in VCL to suspend scrolling, but perhaps there's some obscure macro command to do that?
In general, anything involving graphics operations with NeoJ will be slightly slower than other platforms since it's optimized for Windows/X11 and we have to jump through a number of hoops. On the flip side, however, we're drawing antialiased lines and shapes through Quartz and I don't think the other platforms do that just yet, at least not in 1.1.x
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You cannot download files in this forum
