[poppler] Poppler too slow when compiled with cms

Albert Astals Cid aacid at kde.org
Mon Jan 19 11:00:39 PST 2009

A Dilluns 19 Gener 2009, Koji Otani va escriure:
> From: Albert Astals Cid <aacid at kde.org>
> Subject: Re: [poppler] Poppler too slow when compiled with cms
> Date: Sun, 18 Jan 2009 20:25:03 +0100
> Message-ID: <200901182025.03909.aacid at kde.org>
> aacid> A Diumenge 18 Gener 2009, Carlos Garcia Campos va escriure:
> aacid> > when compiled with cms support enabled poppler is too slow when
> aacid> > rendering some pages. For example, rendering page 831 of PDF
> aacid> > Specification 1.7 takes more than 1 minute in my system.
> aacid> >
> aacid> > Koji, any idea why does it happen?
> aacid>
> aacid> I think the problem is that in this page there's a Pattern, our
> slowest code, aacid> that forces the creation of 272 GfxICCBasedColorSpaces
> that isn't fast aacid> either, but the problem is not the
> GfxICCBasedColorSpaces itself, the problem aacid> is that the pattern
> implementation sucks.
> aacid>
> aacid> To try to bypass this problem we could try implement a kind of cache
> for aacid> GfxColorSpace so you don't have to recreate one if is the same
> as one of the aacid> last N (1-5). This has several implications, like
> adding refcounting to aacid> GfxColorSpace and finding how to know if we
> are asked for the same aacid> GfxColorSpace.
> aacid>
> I think you are right.
> I did quick hack to test only this case. It caches
>  a last GfxICCBasedColorSpace.
>   It created only 3 GfxICCBasedColorSpaces for rendering the page.
>   It took 2 seconds. (before hack, it took 140 seconds)

Can we see the patch? Maybe we can improve it a bit or use it directly.


> -----------------
> Koji Otani

More information about the poppler mailing list