А не нужно откручивать на незнакомой местности! :) (без гида)
Понятно, что можно и на ровном месте разложится. Тут слишком много нюансов чтобы можно было свести к формуле с вероятностями, взять хотя бы точность оценки _предполагаемой_ вероятности, ведь она может отличаться на порядок. Поэтому, я склонен больше доверять экспертному мнению.
Знакомый парапланерист, примерно так отзывался сравнивания с ездой на мото: да, мото опасно, но здесь ты хотя бы видишь опасность, на параплане же например, восходящий поток может появиться буквально на ровном месте — поле вспахано, черное сильнее нагревается, и этого достаточно при неправильном пилотировании чтобы он «завернулся».
(Мото — эндуро, поэтому идиотов на дорогах, в расчет не брали.)
Для того чтобы первая ступень приземлилась ей же нужно будет (в точке возврата) столько же топлива сколько понадобиться для взлета ракете, которая не собирается возвращатся? И это может быть экономически выгодно? Ведь нужно наверное значительно больше топлива на старте, чтобы доставить топливо для приземления до точки отстыковки первой ступени.
Ну так может завести второю коллекцию, которая заточена под те операции которые вам еще нужны. Зачем мучить словарь, если у вас этих операций много, он же не для этого? Опять же под запросы по ParentId (не знаю что там у вас) наверное тоже можно организовать структуру данных.
Мне логика совершенно не понятна, если у вас таких операций может быть 80% процентов, тогда нужно их опимизировать, смысл какой от словаря?!
dictionary.FirstOrDefault(..) — это же вообще через Linq, dictionary.Values.ToArray() — здесь, слишком большие накладные расходы, что там можно про сам dictionary намерить?!
И зачем нужна такая операция для реализации кэша?! Удалять устаревшие?
По графику не понял, если доля операций чтения растет, почему время выполнения тоже растет? Почему 0 при нулевой доле? Время write операций не учитывается?
Не понятно, в чем тут соревнование? ИМХО такая задача может использоваться для отладки/разработки алгоритма управления на начальном этапе, в чем соревнование, в том что смогли подключить интерфейс и управлять автомобилем?
LabView коммерческий продукт? Открытых аналогов нет?
Что то я совсем запутался, вроде раньше писали, что про здание на последней фотке — это не то сколково, которое инновационный центр, это бизнес школа. Я что-то путаю или изменилось?
Хорошая аналогия.
По поводу ошибка или нет, тут нужно учесть, что парсеры для таких сообщений (знаю, что SIP имеет схожий формат точно) делают следующим образом (я других вариантов не встречал): режут исходное сообщение на заголовки и каждый заголовок уже парсят отдельно каким либо способом, причем здесь один вариант — выбирать парсер по имени заголовка, т.е. Content-Length будет парсится отдельно своим парсером. И вот как раз в этом случае, естественным образом получится, что если мы не можем распарсить заголовок предназначеным для него парсером, то возникает ошибка (если этот заголовок важен для нас). Но только это не совсем то поведение которое прописано в rfc.
Понятно, что можно и на ровном месте разложится. Тут слишком много нюансов чтобы можно было свести к формуле с вероятностями, взять хотя бы точность оценки _предполагаемой_ вероятности, ведь она может отличаться на порядок. Поэтому, я склонен больше доверять экспертному мнению.
(Мото — эндуро, поэтому идиотов на дорогах, в расчет не брали.)
А где остальные? Зачитайте весь список, пожалуйста.
Мне логика совершенно не понятна, если у вас таких операций может быть 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 нивелирует их своей жадностью