[cairo] [ft-devel] [PATCHSET] Multithread-safe FreeType
behdad at behdad.org
Sat Jan 3 21:16:53 PST 2015
On 14-12-30 10:25 PM, Werner LEMBERG wrote:
>> The patchset mainly removes use of singleton buffers in favor of
>> stack or per-face allocated ones. In all cases this has no down
>> side. [...]
> Thanks! I'll have a look next year :-)
I've now pushed many more commits out, that fix a couple of invalid memory
accesses, as well as fixing up allocations such that there is no performance
hit whatsoever caused by this branch. If anything, it should speed things up
> Just wondering: How much does
> your patch increase FreeType's memory footprint?
In all cases it should make FreeType allocate and hold onto *less* memory.
The stack consumption has gone up about 20kb (about FT_RENDER_POOL_SIZE +
2kb). There's one exception, which is the bytecode execution context. We now
allocate one of that per face on demand. It's 1kb only.
> What's the behaviour in tight memory situations?
Should be improved. Instead of relying on allocated memory, many places now
use stack memory.
> In particular, there are still a lot of
> programs that don't need thread safety at all, and for such systems I
> would like to avoid any bloated memory consumptions.
The whole thing streamlines a lot of memory allocations, resulting in fewer
allocations in all cases.
> PS: In general, I would like to test FreeType in situations where the
> available memory is largely reduced so that I intentionally get
> many allocation errors. Is there a GNU/Linux tool to restrict the
> available memory of a process or program?
I know both dbus and cairo had tools to do this, but can't find either.
More information about the cairo