[Poppler-bugs] [Bug 68420] Cache lcms transformed values for ICC colorspaces in getRGB(), getCMYK() and getGray()

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=68420

--- Comment #2 from Thomas Freitag <Thomas.Freitag at alfa.de> ---
(In reply to comment #1)
> I think that having a cache is always a good thing, i'm just scared at how
> much memory use it could potentially end up using, sure in your case is just
> a 1MB more over 900MB, wow we really need that much memory? Are you sure
> you're using valgrind right? Actually the correct tool for this would be
> massif.

Sorry about horrifying You with the memory usage, I should have explain that it
is the sum of memory allocated during runtime, not the highwater value during
runtime. I just wanted to point to the fact, that even for the attached PDF
with a very huge using of different colors we just need that 1 MB of memory.
(Keep in mind: because we now use getRGBLine for images, getRGB is only used in
fill and stroke operations now, and so shadings are these painting operations
which are using a lot of getRGB calls with different colors)

> 
> Anyway, what i'm trying to say i'd be much happier with some kind of patch
> if the cache was limited, though obviously that means maitaining a proper
> cache and not just a std::something, which is both harder to code and may
> slow it down a bit.

We can still use the std::map as the cache container but limit it to certain
number of values we cache. I'll make some tests to see how much this would
reduce the speed and if how many values need to be cached by the attached PDF.

> 
> Because if we don't limit the cache it can end up being 64M big, no?

I don't think that we end up with 64M....

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/poppler-bugs/attachments/20130826/0f7e59cf/attachment.html>