LibreOffice 3.5.4: 100% faster

users
#1

Apropos the announcement and referring to "[i]with up to 100% performance
gains when opening large files (depending on operating system, hardware
configuration and file contents)[/i]" in particular, it would be nice if
LibreOffice had a set of "large files" that users could download and check
for themselves before and after installing 3.5.4 so that one variable, file
content, would be out of the way.

#2

Hi :slight_smile:
That sounds like a good plan.  Do you have any such large files that could be uploaded to the wiki?
Regards from
Tom :slight_smile:

#3

Am 31.05.2012 04:57, chimak111 wrote:

Apropos the announcement and referring to "[i]with up to 100% performance
gains when opening large files (depending on operating system, hardware
configuration and file contents)[/i]" in particular, it would be nice if
LibreOffice had a set of "large files" that users could download and check
for themselves before and after installing 3.5.4 so that one variable, file
content, would be out of the way.

--
View this message in context: http://nabble.documentfoundation.org/LibreOffice-3-5-4-100-faster-tp3986920.html
Sent from the Users mailing list archive at Nabble.com.

Since this is the type of news that comes from Italo Vignoli I don't give a shit. He has really no clue.
Interested spreadsheet users can generate huge data sheets within seconds.
With my own files I notice a *small* difference in speed between AOO and LibO3.3 on one side and LibO 3.5 on the other side.

#4

Hi :slight_smile:
Please can we try to keep this mailing-list "family friendly"?  It is a good point that marketing and PR often needs to say things that are not always objective or quantifiable.  A salesman's claim that something is 100% is not the same as a programmers idea of 100% and neither may bear any relation to what wide-eyed-end-users feel that they experience.

Personally i think that when marketing people assign numbers to things they tend to make a complete mess and so they should avoid it.  It is why we now have measurements such as GiB, MiB etc compared to GB, MB etc.  While the "i" is meant to mean absolutely right this time honest guv" marketing people just misuse it just as they misused the original ones so we still don't know whether people mean
1 GB = 1024 MB or just 1000MB
compounded by not knowing if those MBs are 1024 Kb or not, so quoted figures for any measurements can end up being completely useless and nothing to do with real size.

Why can't they just say things like "A LOT faster"??  Why drag in numbers that are likely to be proven wrong in certain/all cases?
Regards from
Tom :slight_smile:

#5

Hi :slight_smile:
Please can we try to keep this mailing-list "family friendly"? It is a good point that marketing and PR often needs to say things that are not always objective or quantifiable. A salesman's claim that something is 100% is not the same as a programmers idea of 100% and neither may bear any relation to what wide-eyed-end-users feel that they experience.

Also, even if the benchmark testing is quantifiable and the speed
increase is very significant users will find the speed increase
variable. What does 100% faster really mean?

#6

PLEASE remove my email address from your list

Thank You

#7

Since *you* added your address to this list, *you* are the one to remove yourself from this list.

#8

Tom wrote

Hi :slight_smile:
That sounds like a good plan.  Do you have any such large files that could
be uploaded to the wiki?
Regards from
Tom :) 
...

Just fill column A down with 1, 2, 3, 4, ... to the very end. That should
give a file large enough to cause enough problems with 3.5.3.2 on my Dell
Inspiron 1545 Core2 Duo with 4 GB RAM.

#9

Hi Tom,

Why can't they just say things like "A LOT faster"?? Why drag in numbers that are likely to be proven wrong in certain/all cases?

Well, probably because the cynic in me knows that someone in the AOO
camp released a statement about AOO 3.4 essentially saying that it was
much faster (by a factor of x, y, z) than LO, and both projects seem to
be content to knock each other about at the slightest occasion (sighs in
disbelief). I have personally always hated the spin that this project
has attempted to put on things to make it sound more attractive than the
"competition" - it was the same thing while OOo was ongoing.

Like Andreas, I generally tend to ignore announcements like that and
prefer factual analysis, but how often is software tested and
statistically significant results given ? errmm....

On my Linux box, with less than one Gig of ram and an old 5400 rpm
harddisk, everything is slow !!!! :wink:

On my Macbook, it depends.

So basically, YMMV - your mileage may vary.

Alex

#10

Alexander Thurgood wrote

... I ...
prefer factual analysis, but how often is software tested and
statistically significant results given ? errmm....

On my Linux box, with less than one Gig of ram and an old 5400 rpm
harddisk, everything is slow !!!! :wink:

On my Macbook, it depends.

So basically, YMMV - your mileage may vary.
...

Not to belabour a point, but that's why I felt that if there was a set of
files available, anyone could use them before and after on their own boxes
with both the old and the new version to see how things are for them in
their situation.

#11

Unfortunately, even then, you could only state something like "With these particular test files, LO is xx% faster."

But, really, so what? In my particular case, I regularly use a large and complex spreadsheet with numerous custom macros. In my case, moving from LO 3.4.x to 3.5.x apparently broke something vital. A process that has taken less than 60 seconds to complete in versions 3.x through 3.4.x now can take 30 minutes or more. Total deal-breaker and major pain in the butt!

So in my own real-(in my)-world test files, v3.5.x is thousands of percent slower! But I do see your point.

2 cents.

#12

Am 31.05.2012 19:08, Chad Neeper wrote:

So in my own real-(in my)-world test files, v3.5.x is thousands of
percent slower! But I do see your point.

This project has too many consumers and fan boys but no "power users".
Apart from that, the time of spreadsheets is over. In the 2020ies hardly anybody will be able to use them. The extreme decline of user skills and education is obvious.

#13

Hi :slight_smile:
Hmmm, pointless bickering amongst ourselves leaves the way clear for the real competition.  "The Popular People's Front".  With so many of people still in both communities it is really ridiculous to compete against each other like that.  Gentle joshing is fine but politicing is pointless. 
Regards from
Tom :slight_smile:

#14

Hi Chad,

But, really, so what? In my particular case, I regularly use a large and
complex spreadsheet with numerous custom macros. In my case, moving from
LO 3.4.x to 3.5.x apparently broke something vital. A process that has
taken less than 60 seconds to complete in versions 3.x through 3.4.x now
can take 30 minutes or more. Total deal-breaker and major pain in the butt!

Have you issued a bug for this? Could you describe the problem and have a sample where it does not work or the speed has slowed?

Cheers,

Marc

#15

Hi :slight_smile:
I think you under-value your own skill-level.  If you don't value your own extremely advanced skill-set then of course you despair of other people that successfully use it a lot but just almost never need to do so at the advanced levels you consider basic. 
Regards from
Tom :slight_smile:

#16

I probably should have mentioned that even though LO v3.5.x killed my spreadsheet performance, I still use v3.5.x because....I like it. So I found a somewhat palatable work-around. I'm perfectly happy to be a power user and fan boy rolled into one!

I'd disagree that the time of spreadsheets (even complex ones) is over, though. There will always be people like me that evolve what starts out as a simple spreadsheet to track a few items...into something that is ridiculously complex and should really be ported to a true database engine! :slight_smile:

#17

I haven't yet completely isolated the problem. I know that it lies within the BASIC code, and know generally what calls are doing it, but haven't gotten further yet. I figured if I eventually narrow it down enough to replicate in a virgin spreadsheet, I'll ask the community and then, depending on comments, file a bug.

#18

Hi Chad,

Hi Chad,

LO 3.4.x to 3.5.x apparently broke something vital. A process that has
taken less than 60 seconds to complete in versions 3.x through 3.4.x now
can take 30 minutes or more. Total deal-breaker and major pain in the
butt!

Have you issued a bug for this? Could you describe the problem and
have a sample where it does not work or the speed has slowed?

I haven't yet completely isolated the problem. I know that it lies
within the BASIC code, and know generally what calls are doing it, but
haven't gotten further yet. I figured if I eventually narrow it down
enough to replicate in a virgin spreadsheet, I'll ask the community and
then, depending on comments, file a bug.

Thanks for the help with debugging. Let us know when you need some people to confirm the bug.

Cheers,

Marc

#19

Hi :slight_smile:
+1
Growth is good :)  A fresh start in a new format can be great but finding time to do it is not always easy!
Regards from
Tom :slight_smile:

#20

...especially when one has to try to interpret mind-bending comments about skill levels...LOL!

I'm driving quickly enough to the nut house on my own. I don't need help, Tom!! :slight_smile: