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

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.


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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]