(нытье, хотя почти development) freetype и fontconfig

> Чудесная библиотека freetype сделана в расчете на то, что после malloc всегда выполняется memset(ptr, 0, size)

Стоит изменить ее функции выделения памяти, и она начинает падать.

Крайне странно. Может, это твой аллокатор - кривой? Пробовал гонять тот же тест, но со стандартным аллокатором и под valgrind?

я аллокатор не делал.

просто закоментарил memset в функциях alloc и realloc)

Если поведение freetype в самом деле зависит от значений в свежеаллоцированном куске памяти, valgrind об этом обязательно напишет. А если не напишет - ищи багу на своей стороне.

см FT_MEM_ZERO в ft_mem_alloc и ft_mem_realloc

freetype-2.3.9, но в 11 вроде тоже самое

нет никакой неинициализированной памяти

я пытаюсь чуть разогнать эту хрень и обнаружил, что куча времени тратится в memset, который вызывается из функций выделения памяти(см пост выше)

> ft_mem_alloc и ft_mem_realloc

Так и писал бы с самого начала, что модифицировал исходный код freetype, и после этого она у тебя стала падать. В таком случае твое исходное сообщение

Чудесная библиотека freetype сделана в расчете на то, что после malloc всегда выполняется memset(ptr, 0, size)

--- яростное 4.2

freetype самостоятельно инициализирует свою память, и законно на это полагается.

я пытаюсь чуть разогнать эту хрень

Хакир?

почему 4.2?

товарищи написали свои функции выделения памяти с занулением, а затем решили, что раз память у нас уже зануляется при выделении, то инициализировать структуры нулями необязательно.

В результате имеем оверхед в виде memset на куски памяти, которые нулями инициализировать и не стоило бы.

ну и имхо решение кривое.

Хакир?

работа такая...

> куча времени тратится в memset, который вызывается из функций выделения памяти

Полагаю, основная масса памяти идет на порождение растеризованных символов, и в любом случае нуждается в инициализации нулями. А так много времени тратится, должно быть, на minor page faults - которые неминуемо случаются при первом обращении к аллоцированной странице.

> В результате имеем оверхед в виде memset на куски памяти, которые нулями инициализировать и не стоило бы.

Тогда valgrind тебе в руки, и добавляй инициализацию во все функции. За одно расскажешь, сильно ли удалось ускорить ,)

>> Полагаю, основная масса памяти идет на порождение растеризованных символов, и в любом случае нуждается в инициализации нулями.

надо будет проверить, но есть подозрение, что придется переделывать...

мне кажеться, что ты часто этот freetyoe дергаешь. Реже надо

эт не я, это gtk

жутковато ему, это ты ещё код M$ не видел.

видел ворованные исходники win2k.

да я понимаю, что линукс - говно, но все остальное еще хуже)

qt тоже очень много дергает

не, я не хочу холивара gtk vs qt :)

мне бы всю эту хрень ускорить процентов на 10-20

переписать алгоритм?

у меня например надо было при рисовании определять какую область занимает такой-то такст таким-то шрифтом (чтоб его обрезать).

Когда я стал тупо кэшировать размеры всех строк одного шрифта, скорость выросла, а объем памяти упал

меня пока напрягает tt_face_load_eblc

придется переделывать выделения памяти в ней похоже.

face_load_eblc разогнался раза в 4-5 путем выделения памяти в статическом массиве для Load_SBit_Range_Codes и Load_SBit_Range.

а не сломал ли ты этим multithread'ность?

может лучше calloc или массив на стэке?

Не сломал, эта функция вызывается всего один раз, т.к. в системе один шрифт.

А то, что это не будет работать на других машинах, где шрифтов много, меня совершенно не волнует.