Быстрее позвонить kind_of?или перебрать массив с одним значением? - PullRequest
0 голосов
/ 22 апреля 2011

Короче говоря, выше ли стоимость (по времени и процессору) для вызова kind_of? дважды или создать новый массив с одним значением, а затем повторить его? В «предыстории» ниже просто подробно объясняется, почему я должен это знать, но это не обязательно чтение, чтобы ответить на вопрос.

Предыстория :

У меня есть куча данных о местоположении. Пары широта / долгота и название места, которое они представляют. Мне нужно отсортировать эти значения широты / долготы по расстоянию от другой пары широта / долгота, предоставленной пользователем. Я должен рассчитать расстояния на лету, а они не известны раньше.

Я думал, что было бы легко сделать это, добавив карту distance => placename в хеш, затем получить набор ключей и отсортировать их, а затем считать значения в этом порядке. Тем не менее, существует вероятность того, что два расстояния будут равны, что сделает два ключа равными друг другу.

Я придумал два решения для этого, либо я отображаю

if hash.has_key?(distance)
  hash[distance].kind_of? Array
   ? hash[distance] << placename
   : hash.merge!({distance => [hash[distance], placename]})
else
  hash.merge!({distance => placename})
end  

тогда при чтении значений проверяю

hash[distance] kind_of? Array ? grab the placename : iterate through hash and grab all placenames 

каждый раз. Или я мог бы сделать каждое значение массивом с самого начала, даже если оно имеет только одно место.

Ответы [ 3 ]

3 голосов
/ 22 апреля 2011

Вероятно, вы потратили больше времени на обдумывание проблемы, чем когда-либо экономите время ЦП. Время, затрачиваемое разработчиками (как на вас, так и на тех, кто будет поддерживать код, когда вас не будет), зачастую намного ценнее циклов ЦП. Сосредоточиться на ясности кода .

Если вы получаете признаки того, что ваш код является узким местом, может быть хорошей идеей является его тестирование, но не забывайте тестировать как до, так и после любые внесенные вами изменения, чтобы убедиться, что вы на самом деле улучшаете код. Удивительно, как часто «оптимизации» вообще не улучшают код, а только затрудняют его чтение.

1 голос
/ 22 апреля 2011

Честно говоря, это звучит как очень незначительная проблема с производительностью, поэтому я бы сказал, что просто делайте то, что вам лучше.

Если вы действительно верите, что это оказывает реальное влияние на производительность (и, честно говоря, есть другие области Ruby, о которых вам следует больше беспокоиться о скорости), уменьшите проблему до простейшей формы, которая все еще напоминает вашу проблему, и используйте Модуль эталонных тестов:

http://www.ruby -doc.org / STDLIB / libdoc / тест / RDoc / index.html

0 голосов
/ 22 апреля 2011

Могу поспорить, что вы достигнете как более высокой производительности, так и лучшей разборчивости, используя встроенный метод Enumerable#group_by.

Как уже говорили другие, вполне вероятно, что это не узкое место, которое приноситв любом случае будет незначительным, и вы должны сосредоточиться на других вещах!

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...