Comments 4
вот всегда было интересно – а как со скоростью?
CLOS вряд ли будет использоваться для написания критических частей числодробилок, где важна эта самая «скорость», а в остальных случаях её оверхед вполне стоит приобретаемой выразительности.
Стандартный CLOS в таких реализациях, как SBCL и CCL, работает достаточно шустро.
Но когда начинается использование кастомных метаклассов, целый ряд оптимизаций
отключается. У меня в одном проекте (встраиваемая система контроля и управления
ускорителя электронов) пришлось от активного использования MOP'а отказаться,
когда понадобилось запускать штуковину на 600MHz ARM'е (Cortex-A8).
Но когда начинается использование кастомных метаклассов, целый ряд оптимизаций
отключается. У меня в одном проекте (встраиваемая система контроля и управления
ускорителя электронов) пришлось от активного использования MOP'а отказаться,
когда понадобилось запускать штуковину на 600MHz ARM'е (Cortex-A8).
Некоторые виды использования метаобъектного протокола могут вносить достаточно значительные издержки, но при этом же его можно использовать и для повышения производительности стандартной CLOS(один из вариантов того, что можно сделать с его помощью — собственно структуры (structure-object) стандартного CL, которые сильно лучше по производительности чем standard-object).
При этом, если сравнивать со скриптовыми языками вроде Python, или же, скажем, с языками с несовершенными на данный момент компиляторами(вроде Go), то производительность CLOS и MOP в топовых реализациях CL(том же SBCL), дает им огромную фору.
При этом, если сравнивать со скриптовыми языками вроде Python, или же, скажем, с языками с несовершенными на данный момент компиляторами(вроде Go), то производительность CLOS и MOP в топовых реализациях CL(том же SBCL), дает им огромную фору.
Sign up to leave a comment.
Метаобъектный протокол Common Lisp на примере реализации прототипной объектной системы