On 9/24/07, Jeff Muizelaar <[EMAIL PROTECTED]> wrote: > One of the reasons a lot of the warnings were kept is too keep the > source code closer to the xpdf upstream to make merging easier. I > haven't looked over these commits thoroughly yet to see how invasive > they are, but keep that in mind when changing code that isn't specific > to poppler.
I understand the need to keep the code unchanged to make merges easier. On the downside, it does preclude making meaningful improvements to the code. To give a few examples I noticed so far: 1. In a lot of places GooString is dynamically allocated even though it could be placed on stack, which could save a malloc() a delete and reduce runtime memory usage. 2. In a lot of places if (foo) gfree(foo) and if (foo) delete foo is used, even though just gfree(foo) and delete foo works just fine and is less code. 3. Speed could probably be improved if SplashBitmap was restructured to avoid switch(mode) in every getPixel() call (e.g. by splitting into a base class and making each variant derive with virtual getPixel()). 4. Based on my profiling, a speed could be improved a lot if lexing/parsing was restructured to not allocate so many temporary objects. But that would impact a lot of code. So how do you decide whether to make a given change or not? How about I'll try to keep changes in master to non-invasive changes and do bigger improvements on a branch and you can decide if you want to merge them or not? -- kjk _______________________________________________ poppler mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/poppler
