Date: prev next · Thread: first prev next last
2013 Archives by date, by thread · List index



I think the real issue for this thread is not 32-bit or 64-bit, but the
performance of Calc.

Yes, it can be much slower than Excel, but not always.

Yes, our developers are working on making the code more "efficient" so
it will work faster.

Efficient 32-bit package can outperform a less efficient 64-bit
version.  Just because the package is a 64-bit package does not mean it
will work better.

I have a single core 64-bit HP laptop [2005 era] running 32-bit XP/pro
that converts .mp4 videos to a DVD player movie format faster than the
dual core 64-bit DELL laptop [2007 era] running 32-bit Vista ever did. 
I have a DELL dual core 64-bit desktop that ran 64-bit Ubuntu 10.04 and
it is slower than a 32-bit desktop that ran Ubuntu 10.04 32-bit. 

In my experience, just because there is a 64-bit version out there, it
does not mean it is better and faster.

The worse OS I have ever used was a 64-bit XP that was used in an office
for number crunching on a dual core 64-bit Intel processor.  It was much
worse than ME or Vista.

So, lets let our developers work on making Calc work more efficient. 
Let them work on all of the legacy code that needs to be updated to make
it run better, faster, etc..  Over the past few years, it seems that
Calc is running a bit faster as Calc gets more code replaced, and as
Java is replaced by Python. [as I was told was being done].

They are working their best, and most of them are volunteers who work on
LO after they get done with their paid jobs.  Of course it is nice that
there are businesses that are providing some help as well.

If we had hundreds of paid code developers, like MSO has, then it would
take less time to get things done.  But then LO would no longer be FREE,
since LO had to sell their office suite to pay for all of the workers
and developers.  That is a lot of money towards payroll we cannot get
from donations.


On 11/08/2013 11:15 AM, Joel Madero wrote:
I've been trying hard to avoid this conversation as it's probably the
1000th time I've seen something similar on the user list but coming
from a developer/QA perspective, I think I can say something brief.
The possible gains for these "power users" would probably be small and
the amount of time to developer a true 64 bit version (on top of these
requests to support 8 cores or whatever else that's requested) would
be IMMENSE. We're talking about tens if not hundreds of thousands of
dollars worth of developer and QA time. If you have a spreadsheet that
is running that miserably I would recommend that any of these "power
users" investigate if they are using spreadsheet correctly (vs.
masking a database within spreadsheet, which is incorrect and in which
case they should be learning how to use Database). I do have a few
spreadsheets that are 40ish megs with quite a few charts and lots of
formulas, but even these I could likely convert to a database if I
took the time and probably see some gains in performance - but even
these run "fast enough" and I would never ask developers to waste
their time for these outlier cases of having insane spreadsheets.

At my old work my employer had made a 1 GB Spreadsheet and always
complained about Excel's limitations - at which point I would quickly
point out "no, although I'd love to pin this on Microsoft, this is in
fact bad implementation on your part." I don't know the details of any
of these Spreadsheets but from what I've seen in the past, these
statements have rung true in most cases.


No offense at all, I encourage open conversation but I tend to see a
one side conversation "THERE SHOULD BE A 64 BIT FLYING LIBREOFFICE
THAT CAN BAKE ME A CAKE AND CALCULATE A QUADRILLION FORMULAS IN
0.0000001 SECONDS USING ALL 16 OF MY CORES!" - without the other side
of the equation - "such a product would be incredibly costly and there
are thousands of much more important things to get done that will
benefit a lot more users."



All the best,
Joel

On 11/08/2013 06:30 AM, Simos Xenitellis wrote:
On Tue, Nov 5, 2013 at 1:26 PM, Tanstaafl <tanstaafl@libertytrek.org>
wrote:

On 2013-11-04 6:09 PM, josip prusina <josip.prusina.croatia@gmail.com>
wrote:

Hi. From where download 64 bit version libreoffice for windows 8.1. 64
bit.
? Link or manual tutorial for download 64 bit version..

Why do you think you need a 64bit version?

Do you have any documents that are larger than 4GB? If so, then you
need
to rethink how you are using Office Applications...


I think the issue is, are there any technical issues that do not make it
easy to have 64-bit LibreOffice packages on Windows?

There are some technical issues, and Firefox is also distributed as a
32-bit package as well (Though you can look and find a 64-bit
packages in
the nightly builds, so power users are happy),
http://thenextweb.com/apps/2012/12/22/mozilla-backpedals-on-firefox-64-bit-for-windows-will-keep-nightly-builds-coming-after-all/


As described at the link above, it's good to figure out with numbers
whether there are cases that a 64-bit LibreOffice has actual benefits
(big
document, etc). Having a 64-bit LibreOffice for Windows will help retain
some power users.

Simos





-- 
To unsubscribe e-mail to: users+unsubscribe@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/users/
All messages sent to this list will be publicly archived and cannot be deleted

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.