Для того чтобы первая ступень приземлилась ей же нужно будет (в точке возврата) столько же топлива сколько понадобиться для взлета ракете, которая не собирается возвращатся? И это может быть экономически выгодно? Ведь нужно наверное значительно больше топлива на старте, чтобы доставить топливо для приземления до точки отстыковки первой ступени.
Ну так может завести второю коллекцию, которая заточена под те операции которые вам еще нужны. Зачем мучить словарь, если у вас этих операций много, он же не для этого? Опять же под запросы по ParentId (не знаю что там у вас) наверное тоже можно организовать структуру данных.
Мне логика совершенно не понятна, если у вас таких операций может быть 80% процентов, тогда нужно их опимизировать, смысл какой от словаря?!
dictionary.FirstOrDefault(..) — это же вообще через Linq, dictionary.Values.ToArray() — здесь, слишком большие накладные расходы, что там можно про сам dictionary намерить?!
И зачем нужна такая операция для реализации кэша?! Удалять устаревшие?
По графику не понял, если доля операций чтения растет, почему время выполнения тоже растет? Почему 0 при нулевой доле? Время write операций не учитывается?
Не понятно, в чем тут соревнование? ИМХО такая задача может использоваться для отладки/разработки алгоритма управления на начальном этапе, в чем соревнование, в том что смогли подключить интерфейс и управлять автомобилем?
LabView коммерческий продукт? Открытых аналогов нет?
Что то я совсем запутался, вроде раньше писали, что про здание на последней фотке — это не то сколково, которое инновационный центр, это бизнес школа. Я что-то путаю или изменилось?
Хорошая аналогия.
По поводу ошибка или нет, тут нужно учесть, что парсеры для таких сообщений (знаю, что SIP имеет схожий формат точно) делают следующим образом (я других вариантов не встречал): режут исходное сообщение на заголовки и каждый заголовок уже парсят отдельно каким либо способом, причем здесь один вариант — выбирать парсер по имени заголовка, т.е. Content-Length будет парсится отдельно своим парсером. И вот как раз в этом случае, естественным образом получится, что если мы не можем распарсить заголовок предназначеным для него парсером, то возникает ошибка (если этот заголовок важен для нас). Но только это не совсем то поведение которое прописано в rfc.
Согласно схемы это будет правильный extension-header заголовок.
Да, я с этим согласен.
Может это конечно мое восприятие смещено, но мне кажется что допустим такое сообщение:
HTTP/1.0 200 OK
Date: Fri, 31 Dec 1999 23:59:59 GMT
Content-Type: text/html
Content-Length: здесь фигня какая-то вместо цифр
должно считаться не валидным.
Сейчас получиться что оно валидно, но вместо Content-Length получим extension-header. У меня в реальности, в моей задачи такое поведение очень досаждает, выходит так что невозможно проверить синтаксическую корректность сообщения, и очевидные синтаксические ошибки проваливаются на другой уровень.
Мне логика совершенно не понятна, если у вас таких операций может быть 80% процентов, тогда нужно их опимизировать, смысл какой от словаря?!
И зачем нужна такая операция для реализации кэша?! Удалять устаревшие?
blogs.msdn.com/b/pedram/archive/2007/10/07/a-performance-comparison-of-readerwriterlockslim-with-readerwriterlock.aspx
Оно понятно, но такие «соревнования» должна проводить команда ежедневно просто во время разработки.
>А LabVIEW — коммерческий продукт
Коммерческий, закрытый — какая задача ставилась, показать возмножность?
LabView коммерческий продукт? Открытых аналогов нет?
По поводу ошибка или нет, тут нужно учесть, что парсеры для таких сообщений (знаю, что SIP имеет схожий формат точно) делают следующим образом (я других вариантов не встречал): режут исходное сообщение на заголовки и каждый заголовок уже парсят отдельно каким либо способом, причем здесь один вариант — выбирать парсер по имени заголовка, т.е. Content-Length будет парсится отдельно своим парсером. И вот как раз в этом случае, естественным образом получится, что если мы не можем распарсить заголовок предназначеным для него парсером, то возникает ошибка (если этот заголовок важен для нас). Но только это не совсем то поведение которое прописано в rfc.
Content-Length = "Content-Length" ":" 1*DIGITпросто получается, что extension-header нивелирует их своей жадностью
Так ведь extension-header с именем Content-Length никто обрабатывать не будет, а ошибка есть.
Да, я с этим согласен.
Может это конечно мое восприятие смещено, но мне кажется что допустим такое сообщение:
должно считаться не валидным.
Сейчас получиться что оно валидно, но вместо Content-Length получим extension-header. У меня в реальности, в моей задачи такое поведение очень досаждает, выходит так что невозможно проверить синтаксическую корректность сообщения, и очевидные синтаксические ошибки проваливаются на другой уровень.
Печально.