Search
Write a publication
Pull to refresh
1
0
Send message

Данный вид бенчмаркинга — в чистом виде лукавство. Просто удивлён даже, насколько это лукаво и ужасно.


  1. Считаю, что некорректно оставлять создание объекта (не важно каким способом) внутри измеряемого пространства. Поскольку в любом случае объект будет создан хотя бы один раз и ресурсы будут потрачены неизбежно и причём одинаковые.
  2. При подобном подходе в написании бенчмарка вполне естественно, что возврат объекта в виде указателя будет нести с собой бОльший оверхед за счёт gc, это ясно как дважды два, зачем это делать — непонятно, и что таким образом хотелось продемонстрировать тоже не ясно.
  3. Самое главное. Если следовать заданному в статье введению, то речь идёт именно о совместном использовании. А если говорить о совместном использовании, то надо говорить о передаче объекта в произвольную функцию. Здесь то и начинается самое важное. Если передавать объект по значению, то при данной операции неизбежно будет выполнена новая аллокация копии объекта целиком. Если объект состоит из двух полей int, то здесь и говорить не о чем, а теперь подумайте если объект содержит в одном из полей массив на 100 000 элементов. Есть смысл сравнивать аллокацию такого нового объекта с аллокацией переменной под указатель и временем для последующего сбора gc? Вопрос риторический.
  4. Прочитав эту статью меня больше всего насторожило, что ни в одном комментарии никто не обратил на это внимание. Главное зло статьи в том, что у начинающих разработчиков может создаться иллюзия того, что не стоит заморачиваться и использовать указатели… «человек вон доказал бенчмарками, что разницы нет!». А доказательство это — чистой воды лукавство и ввод в заблуждение. Измените 3 строки в тесте и вы увидите реальное положение дел.
  5. Данная статья годна только для ответа на вопрос «стоит ли создавать объект в виде указателя при инициализации, не планируя его совместное использование»… то есть, вопрос сам по себе довольно утопичен.

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

Довольно странно рассуждаете. Вот именно в Вашей ситуации и необходимо учитывать все по UTC без анализа часовых поясов, и только тогда Вам не придётся думать у кого какое локальное время, а расчёт вашей логистики сведётся к анализу доступности маршрутов и рабочих часов каждого из сегментов, поскольку все они приведены к UTC...

Information

Rating
Does not participate
Registered
Activity