https://bugs.freedesktop.org/show_bug.cgi?id=62656
--- Comment #17 from [email protected] --- Presumably you refer to the 1973 Honda Civic with the 1.1L engine and curb weight of 1500 pounds. https://en.wikipedia.org/wiki/Honda_Civic_%28first_generation%29 There is also, albeit only sold in Japan, the 2007 FD2 Civic Type-R with a 225-horse engine, and a stock curb weight of 2800 pounds, top speed 150 mph right from the manufacturer. http://hondatyper.com/Civic-Type-R.html There is even the special-edition only-300-sold Mugen-racing-subsidiary Honda Civic Double-R at 237 HP and 2767 pounds, which means ~160 mph max. http://www.modified.com/features/sportculture-feature-010208/viewall.html Now, that's measured on the flat, with no tail-wind, and a nominal driver weighing 250 pounds or something standardized like that. I'd be willing to bet that, by shaving off some of the 1250-pound mass-differential between the 1973 economy model and the 2007 racing model, you could quite easily have a Civic that hit the 200mph mark... especially if you were willing to run the test with a tailwind and a steep downhill grade. But, that would be cheating, right? Because the point of the top-speed measurements is to give a performance benchmark, under standardized conditions. But the engineering reason that I am suggesting we can boost the *perceived* and also the *effective* performance of LiO, for opening large complex documents, is also cheating.... I'm trying to say that we should be opening the 1800-page docx, by first running as fast as we can from point A to point B, which is to render the first few pages of the document on-screen. That is all the the enduser cares about, usually, in a wide variety of use-cases. Then, second of all, while they are reading page#0 and page#1, which are already onscreen, LiO can keep chugging along in the background, rendering (in RAM rather than in the GPU's visible-onscreen-right-now-framebuffer) the remainder of the complex document in question. That is "2 seconds". This is not a case of us needing to reverse engineer Microsoft's format. That's already been accomplished, for the most part. This is not a case of us needing to render correctly. This is a case of our app being CPU bound, because we are trying to render for layout all two-thousand-odd footnotes, before we even display the first few pages to the enduser. Is Microsoft already using my trick? Well then, maybe 2 seconds is in fact unreasonable. But if they aren't, then 2 seconds may well be achievable. Quite frankly, I had to really strive to be fair and specify 2000 milliseconds, an interminably long time for fiddling with a local file pulled from the hard drive at 80MB/sec plus a few milliseconds of seek. Even the 27mb docx is going to be fully in ram within about 400ms, and we know that *some* small test docx can render the first couple of pages in sub-second times. Which suggests that 2 seconds is very reasonable, indeed. I'd like to be faster, actually. But first things first. And by that I mean: let us agree to stop thinking of Microsoft as the leader, and us as the followers. Look at the LiMa project, which is reverse-engineering the Mali GPU drivers for tablets and smartphones -- their binaries are in many cases *faster* than the stock ones from ARM... and Luc claims he might be able to be another 60% faster in a foreseeably short timeframe. Why not us? Let us strive to shave the excess from the curb-weight, and to increase the size of the carbon-fiber airbox, and to cheat by measuring speed on a downhill grade with a tail-wind. That is all the quickstarter is, after all: cheating. Very effective cheating, and totally ethical, because it really does speed things up for actual endusers. If the fine folks at Honda really wanted to help actual endusers, rather than making their Civic go 200mph, they would bump it to 140 or 150 or 160, and then concentrate on quality. (Which is what they *did* now isn't it?) I'm not going to complain if LibreOffice never makes it to the equivalent of a 200mph sedan. But right now, we can assume that Microsoft is the equivalent of the Chevy Tahoe, 320 HP, 5400 pounds, and top speed 139mph. https://en.wikipedia.org/wiki/Chevrolet_Tahoe#2007.E2.80.932014_.28GMT900.29 http://www.automobile-catalog.com/car/2013/1769015/chevrolet_tahoe_ppv.html LibreOffice, when dealing with complex files, simply cannot keep up. We're 20x slower the msftWord on docx files with lots of footnotes. That means we're going about 7mph -- the tranny is stuck in 1st gear. But if we can get out of first, and shift all the way to sixth gear, then even if our engine is only 200 HP, we can still beat Microsoft, as long as our curb-weight (aka feature-bloat) is 3500 pounds or less. If we really want speed, we can build a motorcycle with that same engine, and call it LibreAbi or LibreMeric or something... but that's optional. I'm *not* here to complain. I'm here to help. But this is not the first time I've lurked on performance-related bug reports. LibreOffice has been slow for a long time. This is not anyone's fault really -- first we had to reverse-engineer the fileformats, then we had to overcome the inertia of Sun and Oracle with their differing agendas, and finally we had to keep something like feature-parity. But now is the time for LiO to start moving faster. The core of LiO is weak, at the moment, in terms of raw performance. But there is nothing holding us back from making fixes, anymore. The core of winword is *not* very strong now. They are pre-occupied with The Ribbon, and The Metro, and all sorts of other stuff. The computerized equivalent of big fins flanking the trunk. LibreOffice has a chance to be like Honda, and build an efficient set of vehicles that get great gas mileage, cost less, run better, and flat out win the engineering contest. My assertion is that people care about fast, effective editing of complex documents. If we make those people happy, LibreOffice will prosper, the folks over at ApacheOpenOffice will cheer, and poor Microsoft will fall by the wayside. GoogleDocs is too simplistic. AbiWord is too simplistic. LibreOffice is the right level of power... but we need to tune that power towards a useful purpose. Anyways, apologies for filling up your inbox, for the third time today. I do not mean to make you unhappy; I get the feeling, when you say that my comment is not useful, and needs to be addressed, that you see it as whining for the impossible. But as I've tried to show, there are solid engineering reasons to believe I'm not whining. Okay, to be fair: not *just* whining, but also have a point. :-) That does not mean I'm 100% correct in all particulars -- maybe it is impossible to render the first couple pages quickly, because the fileformat is so poorly designed that we cannot be sure how the first page will render, until we have in fact rendered every subsequent page. (I've seen HTML+CSS monstrosities just like that in fact.) But let's find out. Let's not settle for LibreOffice being no-more-than-twice-as-slow-as-winword, because that will not bring us tons of converts. Let's aim to win, not aim for second. Since this is getting somewhat off-topic for this particular bug, I am happy to continue it via email, if anybody cares to. In particular, I would like to know what the recommended setup is for performance profiling. Michael Meeks mentioned cachegrind, which I've used once or twice, and Pierre mentioned doing some performance graphs using chrome, and I've done something similar. LibreOffice is pretty huge, though, so I'm not sure cachegrind output is going to make sense to me. Viva la Libre Office. -- You are receiving this mail because: You are the assignee for the bug.
_______________________________________________ Libreoffice-bugs mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
