Хранение данных в расширении ruby ​​C - ужасная идея или нет?

Question

Моя команда работает на сервере MMO в Ruby, и мы решили начать переводить интенсивные вычисления в расширение C. В рамках этого усилия мы перенесли фактическое хранилище данных в C (используя Data_Get_Struct и все такое). Так, например, каждый объект Ruby «Zone» имеет связанную структуру «ZoneKernel :: Zone» C, где хранятся фактические двоичные данные.

В принципе, мне интересно, это ужасная идея или нет. Я не очень хорошо знаком с внутренними компонентами ruby, но кажется, что данные должны быть точными до тех пор, пока родительская зона остается в памяти на рубиновой стороне (таким образом предотвращая сбор мусора из данных C).

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

Answer 1

Как указано в the documentation to Data_Wrap_Struct(klass, mark, free, ptr) function:

free аргумент функции, чтобы освободить выделение указателя. Если это -1, указатель будет просто освобожден.

Эти функции mark/free вызывается во время выполнения GC.

Ваша обернутая собственная структура будет автоматически освобождена при завершении соответствующего объекта Ruby. Пока это не произойдет, ваши данные не будут освобождены, если вы не сделаете это вручную.

Написание C расширений не гарантия повышение производительности, но это почти всегда увеличивает сложность вашего кода. Профилируйте свой сервер, чтобы измерить прирост производительности, и разработайте класс Zone в чистом Ruby, если он будет жизнеспособным.

Answer 2

В общем, мне нравится хранить любые данные, которые могут измениться за пределами моего источника. Загрузка его из YAML или базы данных означает, что вы можете настроить данные в своем сердце без необходимости перекомпиляции. Очевидно, что если время компиляции и время загрузки бывают быстрыми, то это не такая уж большая проблема, но все же неплохо отделить их.

Я пользуюсь YAML, потому что это стандартный формат, поэтому вы можете получить доступ к тому же файлу с любого количества языков. Вы можете загрузить его непосредственно на сторону C или на сторону Ruby, в зависимости от того, что кажется более быстрым/умным.