| Summary: | [patch] fix "length bigger than vheaTab size" and "length bigger than vmtxTab size" | ||
|---|---|---|---|
| Product: | poppler | Reporter: | William Bader <williambader> |
| Component: | general | Assignee: | poppler-bugs <poppler-bugs> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | CC: | williambader |
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: | patch to fix a FoFiTrueType test and to use alloca in GooString::appendfv() | ||
|
Description
William Bader
2015-02-11 06:14:42 UTC
The PDF is at https://dl.dropboxusercontent.com/u/9451086/2-DESCR_648853%20IT-EN-DE_MANITOU_RIGENERATO.pdf These three changes are unrelated and should be split into three separate commits. My only concern with the alloca change is ensuring the stack usage is not too large. > argsSize = 8; > +#if HAVE_ALLOCA_H > + args = (GooStringFormatArg *)alloca(argsSize * sizeof(GooStringFormatArg)); > +#else This is a fixed size allocation that I estimate to be up to 544 bytes so it should be fine. > argsSize *= 2; > +#if HAVE_ALLOCA_H > + { > + GooStringFormatArg *new_args = (GooStringFormatArg > *)alloca(argsSize * sizeof(GooStringFormatArg)); > + memcpy(new_args, args, argsLen); > + args = new_args; > + } > +#else It looks like the allocation is increased if there are more than 8 format args. I have not searched the code to see if there are more than 8 format args used. I'm guessing this is unlikely so maybe when there are more than 8 args we could fallback to using gmallocn/greallocn. If > 8 args is rare there will be little performance impact but it does put an upper bound on the stack usage. > +#if HAVE_ALLOCA_H > +#else > gfree(args); > +#endif #ifndef HAVE_ALLOCA_H gfree(args); #endif would be better. > +#if 0 > int FlateStream::getChar() { > if (pred) { > return pred->getChar(); > } > return doGetRawChar(); > } > +#endif I don't see any need for keeping this. It will always be in the git history. I had trouble understanding what the timings you provided are referring to. Could you provide separate times for master, master + alloca change, and master + alloc + inline change. Thanks for looking at it. >These three changes are unrelated and should be split into three separate commits. Later today, I will make a patch with just the FoFiTrueType patch here and open separate reports for the alloca change and the Flate change. >#ifndef HAVE_ALLOCA_H I did that intentionally for symmetry with the allocation to make it clear that the other case was not forgotten. I do that in my own code, but I will make the new patch match the style in poppler. >I had trouble understanding what the timings The timings are after the change. The alloca change made appendfv() about 5% faster. The FlateStream change had no effect. Some of the other streams inline their getChar() also, but I suspect that all of the stream getChar() functions are called from places that gcc can not tell the Stream type at compile time. I ran several pdftoxxx utilities because the person who reported the performance issues did not say what output device he was using. On my laptop, pdftocairo is significantly faster than pdftoppm because cairo uses assembly code that takes advantage of vector instructions while splash is pure C++. The person who reported the issue had an ARM CPU, and the coding of the output method and the display hardware could make a big difference. For example, we have a RaspberryPi running Fedora, and moving windows on the console is so slow that you can see the pixels paint, like the first time that I ran X on a 20MHz 386 nearly 30 years ago. I've pushed the off by one fix to FoFiTrueType, thanks for catching! Please open different bugs for the rest. Thanks. The gmallocn() GooString::appendfv() patch is in https://bugs.freedesktop.org/show_bug.cgi?id=89096 The Stream inline patch is in https://bugs.freedesktop.org/show_bug.cgi?id=89097
Comment 6
bholeshankar1992crax@gmail.com (Spammer; Account disabled)
2019-05-15 06:34:37 UTC
Comment hidden (spam)
This is great. I Understand when we face problems in playing Xbox live. here https://freexboxlive.xyz/ you can play Xbox and become a free member of Xbox gold. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.