Re: [ft-devel] [PATCHSET] Multithread-safe FreeType

[Behdad Esfahbod]

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
a bit.


> 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.


>     Werner
> 
> 
> 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.


-- 
behdad
http://behdad.org/