make-instance занимает 524 000 байт и занимает 4 мс - PullRequest
Новая
       13

make-instance занимает 524 000 байт и занимает 4 мс

2 голосов
/ 14 апреля 2019 
(time (make-instance 'Flat-Key :key "hello world" :fragment 1))

Урожайность: 

Evaluation took:  
  0.005 seconds of real time  
  0.004367 seconds of total run time (0.004333 user, 0.000034 system)  
  80.00% CPU  
  22 lambdas converted  
  11,382,613 processor cycles  
  524,032 bytes consed

#<FLAT-KEY ((:KEY "hello world") (:HASH 1308457856027851121) (:BUCKET-INDEX 7)
        (:HASH-AS-MASK "1228937CD01BF9-7-1")) {10045AB573}>

Нормальны ли эти суммы?
Если нет, как я могу улучшить свой код?
Если это нормально, что это вызывает?

Второй и третий вызов #'time in в ± 2,5 мсек и до сих пор содержит ± 500k байт (при втором вызове был удален метод #'print-object).

Я использую SBCL в сессии Emacs-slime. Определение класса имеет 4 слота. #'print-object делает некоторую работу; то есть он форматирует лениво вычисленный хэш). Но даже при удалении #'print-object это занимает 2 мс и составляет ± 500 тыс. Байт.
Класс и его функции загружаются с помощью quickload quicklisp (я не уверен, скомпилировал ли quicklisp код или нет; слизь slime-compile-file не влияет на скорость или количество байтов).

Flat-Key: 

(defclass Flat-Key (Key)
  ()
  (:documentation
   "Keys without any level of nesting as used in conventional hash-tries and
Prokopecs CTrie."))

Key - это: 

(defclass Key ()
  ((val :initarg :key
    :reader get-key
    :documentation
    "The value of this Key")
   (hash :initarg :hash
     :initform nil
     :documentation
     "Cached `sxhash` of `key-val`, when nil it can be calculated.")
   (hash-fragment-index :initarg :fragment
            :reader get-fragment-index
            :documentation
            "The level in the trie for which `bucket-index` is valid.")
   (bucket-index :initform nil
         :documentation
         "Cached index into the `CNode's` `Bitindexed-List`."))
  (:documentation
   "Common base of all keys in a Trie"))

In Didier Verna Эффективность CLOS: реализация: о поведении и производительности Lisp, часть 2.1 Международная конференция Lisp ILC 2009, март 2009, Кембридж, США. Материалы конференции ILC 2009, 2009. (доступно через https://hal.archives -ouvertes.fr / hal-01543396 / document ), Дидье Верна измеряет миллионы вызовов `# 'make-instance' за этот промежуток времени.

CLOS make-instance действительно медленный и вызывает исчерпание кучи в SBCL также составляет около #'make-instance и количество операций, но, похоже, nrz делает более сложные вещи , И я не думаю, что смогу применить совет Райнера Йосвига в моей ситуации.

ТЛ; др

Это нормально, что #'make-instance с классом из 4 слотов занимает 2 мс-5 мс и составляет 400-500 тыс. Байт?
Если нет, то что я делаю не так?
Если нормально, что происходит?

1 Ответ

3 голосов
/ 15 апреля 2019

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

  • Сравнительный анализ одного вызова может дать ненадежные результаты, если функция работает быстро.Почему бы не скомпилировать функцию для создания экземпляра N раз и найти значение N, чтобы дать вам время выполнения около 5 с, а затем посмотреть на среднее значение.(Дэн Робертсон)

  • Также поместите код в скомпилированную функцию, а не записывайте его непосредственно в REPL.Хотя REPL компилирует форму ввода, SBCL не оптимизирует ее так же, как для функций.(jkiiski)

  • Первый make-instance может иметь служебную информацию, если ему нужно вызвать finalize-inheritance.Возможно, вы захотите позвонить себе, чтобы исключить эти накладные расходы из последующих вызовов.

  • Обратите внимание, что, позвонив (sb-ext:gc :full t) до time, вы обычно получаете меньшеразница в результатах, устраняя один источник «шума» в ваших измерениях.

  • Слизь / Суонк должен обмениваться данными, а в режиме ожидания на Лиспе с Слизью динамическое пространство -размер медленно увеличивается со временем (и сжимается после каждого gc).Этого не происходит с неослабленной средой.Это может не сильно повлиять на time, но вы никогда не узнаете.

...