Какой-то странный тест производительности.
Мы с коллегами тоже участвовали в конкурсе, у нас свои методы тестирования производительности, как нам кажется, более объективные cloud.mail.ru/public/CZJu/iunQzxYW6 (bash скрипты), и у нас предложенные в конкурсном репозитории решения показали совсем другие цифры.
Ещё один вопрос.
Можно ли изменять входные данные? Т.е. если его изменить таким образом, что его повторное использование будет не возможно, то это нормально?
Это было нечто вроде сарказма, насчёт сторонних решений :)
В той ссылке что вы дали написано, кстати, что integer indexes(*) in ascending order и strings in creation order
Ещё раз повторюсь, вопрос не в том как это работает (это известно), а в том как будут проверять :) А проверять можно по-разному, можно, например, не учесть некоторых деталей.
Ок, забыл уточнить, что при использовании в качестве ключа не числового значения (а у нас как раз такое) порядок будет таким каким он задаётся в подавляющем большинстве случаев [99.(99)%]. Да не гарантируется, да порядок может поменяться! Но вы сами сталкивались хоть раз с такой ситуацией, чтобы _не числовые_ ключи возвращались вам отсортированными просто так, без каких либо усилий с вашей стороны (или с другим порядком)? Вообще, я где-то читал, что даже есть правило о том, что ключи объекта должны перебираться в том порядке в котором были созданы, оно не задокументировано в стандарте, но так работает.
Хорошо, если будет deepEqual, но всякое может быть. Просто решил уточнить.
А JSON.stringify тут притом, что я не догадался, что можно тут можно использовать сторонние решения :D
Я всего лишь написал как я бы сделал :) Я перфекционист, поэтому я не буду объявлять о конкурсе пока не подготовлю всё для него и не буду уверен, что это будет удобно.
Согласитесь, это соревнование и как в любом соревновании надо примерно понимать где ты находишься. Когда спортсмены соревнуются в беге или прыжках в длину/высоту/глубину, устраивают гонки и ещё много в чём соревнуются, то они знают примерно где они находятся в данный момент времени в турнирной таблице (за исключением тех видов спорта где есть очередь и вы не первый кандидат). Вы бы пошли на соревнования по бегу если бы каждого из участников загоняли на стадион по очереди и заставляли бегать на время, при этом никто кроме судьи не видит и не знает о результатах и сообщает о том кто выиграл через неделю, например? Я бы не пошёл, т.к. в такой реализации нет прозрачности, нет уверенности в том, что всё проходит честно. Я думаю вы согласитесь, что намного приятнее бегать всем вместе, чтобы знать когда и на сколько нужно поднажать, чтобы вырваться вперёд.
Только не пишите о том, что я ною или придираюсь! :) Я тоже рад, что конкурс вообще есть, но был бы ещё рад, если бы его организовали лучшим образом. Я всего лишь пишу о том как сделал бы я на их месте и это не значит, что у текущей реализации конкурса всё плохо, может у организаторов другое представление о соревнованиях, которым они не делятся с участниками конкурса (и всем остальным миром), отсюда и негодование/непонимание/возмущения и т.п.
В данном случае получается соревнование с самим собой, целью которой является написать реализацию, которая работает быстрее предыдущей твоей же реализации и нет знания о том, что можно сделать ещё быстрее или о том, что ты впереди планеты всей и никто не реализовал более быстрый алгоритм, чем ты.
Тем более можно было взять, например, уменьшить призы на 100 баксов и на разницу нанять фрилансера, который бы сделал страничку и сделал бы серверную часть, которая делала бы замеры и хранила результаты. Я уверен, что обрабатывать входящие сообщения будет дороже, чем автоматизировать это и любоваться графиками.
Я не эксперт, но карму слили скорее всего из-за плохой организации. Надо было запилить на сайте форму куда можно загрузить скрипт и узнать свой результат, плюс посмотреть предварительно на каком месте находится загруженное решение. Сделать ограничение по несколько загрузок в день от каждого пользователя, конкурс был бы прозрачнее и было бы счастье. Я понимаю, что слишком многого хочу, это всего лишь моё представление того как я бы организовал подобного рода мероприятие. С таким подходом было бы меньше вопросов и возмущений, наверняка.
Согласен, цифра бесполезная:) Забыл затолкать всё что после первого абзаца в спойлер…
Была бы ещё эта статистика, мне известна… Мне кажется, что если какой-то анализ входных данных проводить, то можно получить вариант медленнее, чем один алгоритм ориентированный на универсальный набор данных. Надо будет попробовать:)
Я всего лишь отметил, что никто не знает с вероятностью 100% о том как выглядит почтовый ящик типичного пользователя :) И я не считаю свой ящик — ящиком типичного пользователя :)
У меня скрипт с тестовыми данными выложенными выше (http://habrahabr.ru/company/hola/blog/270847/#comment_8654795) выполняется за чуть больше секунды на i5-4570 (3.2GHz).
Хотя я думал над тем, что если знать как будет выглядеть тестовый набор данных, то можно будет ещё что-нибудь придумать и оптимизировать алгоритм ещё лучше.
У всех почтовый ящик выглядит по-разному. Кто-то получает тоннами спам с разных адресов, а кто-то очень активно переписывается с несколькими людьми и не получает спам.
Спасибо!
Жаль, что эталонная реализация может принимать только 10 сообщений, разницу между сообщениями и правилами как в реальности (несколько порядоков) они не учли=(
Все строковые значения во входных данных непустые и содержат только символы ASCII в диапазоне от 0x20 до 0x7F включительно.
www.bluesock.org/~willg/dev/ascii.html
0x7F — это же del…
И вы уверены, что прямо во всех строковых значениях во входных данных (в т.ч. и в адресах почтовых ящиков) можно использовать все эти символы?
И как быть с ситуацией когда нужно в правилах указать наличие символа * как этого символа, а не как эквивалент любого количества любых символов? Если такие случаи надо учитывать, то реализация будет сложнее и как следствие медленнее.
Вывод: нужно выложить «тесты на корректность», которые вы будете гонять. Вы облегчите этим себе жизнь. Или хотя бы пачку входных данных, которые используются в «тестах на корректность».
Мы с коллегами тоже участвовали в конкурсе, у нас свои методы тестирования производительности, как нам кажется, более объективные cloud.mail.ru/public/CZJu/iunQzxYW6 (bash скрипты), и у нас предложенные в конкурсном репозитории решения показали совсем другие цифры.
Можно ли изменять входные данные? Т.е. если его изменить таким образом, что его повторное использование будет не возможно, то это нормально?
Время инициализации присланного вам модуля будет учитываться или вы будете учитывать только время выполнения фильтрации?
В той ссылке что вы дали написано, кстати, что
integer indexes(*) in ascending order и strings in creation order
Ещё раз повторюсь, вопрос не в том как это работает (это известно), а в том как будут проверять :) А проверять можно по-разному, можно, например, не учесть некоторых деталей.
Хорошо, если будет deepEqual, но всякое может быть. Просто решил уточнить.
А JSON.stringify тут притом, что я не догадался, что можно тут можно использовать сторонние решения :D
Так:
или так:
К сожалению, есть разница
придёт
То тест на корректность будет пройден или нет?
Согласитесь, это соревнование и как в любом соревновании надо примерно понимать где ты находишься. Когда спортсмены соревнуются в беге или прыжках в длину/высоту/глубину, устраивают гонки и ещё много в чём соревнуются, то они знают примерно где они находятся в данный момент времени в турнирной таблице (за исключением тех видов спорта где есть очередь и вы не первый кандидат). Вы бы пошли на соревнования по бегу если бы каждого из участников загоняли на стадион по очереди и заставляли бегать на время, при этом никто кроме судьи не видит и не знает о результатах и сообщает о том кто выиграл через неделю, например? Я бы не пошёл, т.к. в такой реализации нет прозрачности, нет уверенности в том, что всё проходит честно. Я думаю вы согласитесь, что намного приятнее бегать всем вместе, чтобы знать когда и на сколько нужно поднажать, чтобы вырваться вперёд.
Только не пишите о том, что я ною или придираюсь! :) Я тоже рад, что конкурс вообще есть, но был бы ещё рад, если бы его организовали лучшим образом. Я всего лишь пишу о том как сделал бы я на их месте и это не значит, что у текущей реализации конкурса всё плохо, может у организаторов другое представление о соревнованиях, которым они не делятся с участниками конкурса (и всем остальным миром), отсюда и негодование/непонимание/возмущения и т.п.
В данном случае получается соревнование с самим собой, целью которой является написать реализацию, которая работает быстрее предыдущей твоей же реализации и нет знания о том, что можно сделать ещё быстрее или о том, что ты впереди планеты всей и никто не реализовал более быстрый алгоритм, чем ты.
Тем более можно было взять, например, уменьшить призы на 100 баксов и на разницу нанять фрилансера, который бы сделал страничку и сделал бы серверную часть, которая делала бы замеры и хранила результаты. Я уверен, что обрабатывать входящие сообщения будет дороже, чем автоматизировать это и любоваться графиками.
Была бы ещё эта статистика, мне известна… Мне кажется, что если какой-то анализ входных данных проводить, то можно получить вариант медленнее, чем один алгоритм ориентированный на универсальный набор данных. Надо будет попробовать:)
У меня скрипт с тестовыми данными выложенными выше (http://habrahabr.ru/company/hola/blog/270847/#comment_8654795) выполняется за чуть больше секунды на i5-4570 (3.2GHz).
Хотя я думал над тем, что если знать как будет выглядеть тестовый набор данных, то можно будет ещё что-нибудь придумать и оптимизировать алгоритм ещё лучше.
Жаль, что эталонная реализация может принимать только 10 сообщений, разницу между сообщениями и правилами как в реальности (несколько порядоков) они не учли=(
0x7F — это же del…
И вы уверены, что прямо во всех строковых значениях во входных данных (в т.ч. и в адресах почтовых ящиков) можно использовать все эти символы?
И как быть с ситуацией когда нужно в правилах указать наличие символа * как этого символа, а не как эквивалент любого количества любых символов? Если такие случаи надо учитывать, то реализация будет сложнее и как следствие медленнее.
Вывод: нужно выложить «тесты на корректность», которые вы будете гонять. Вы облегчите этим себе жизнь. Или хотя бы пачку входных данных, которые используются в «тестах на корректность».