Я обычно для этих целей использую субрепозитории в Mercurial или Git.
Каждая подключаемая библиотека вервионируется в своем репо, который подключается к проекту- потребителю.
Смена версии библиотеки, при этом, это отдельный коммит с тестированием.
По видимому систему придется отключать в сложных метеоусловиях или при загруженности дорог, но этот прототип по качеству уже достаточен для коммерческой реализации в качестве видеорегистратора например. Можно подмаргивать светодиодом и попискивать при уходе с полосы.
Для определения того, что водитель действительно хочет перестроиться достаточно должно быть включенных поворотников. И это кстати, хороший способ ненавязчиво напомнить о том, что их надо включать. ;)
Кроме того, как себя помню, все это должно хорошо помогать начинающим водителям.
Спасибо! Появился повод все еще раз перепроверить. Но ошибки не обнаружил.
Вот такой код на моей машине выполняется примерно 10 секунд (визуально и по системным часам).
Код замера интервала времени выполнения эквивалентен опубликованному.
Код логирования будет работать чуть быстрее чем в NLog за счет статических членов.
using System;
using System.Diagnostics;
namespace LogBenchmark
{
class Program
{
private static volatile bool _showLog = true;
static void Main(string[] args)
{
_showLog = false;
Console.WriteLine("Frequency:{0}", Stopwatch.Frequency);
int R = 1000000000;
DateTime begin = DateTime.UtcNow;
long none = Measure(None, R);
long p3 = Measure(NCh_P3, R);
Console.WriteLine("Elapsed: {0}", DateTime.UtcNow - begin);
Спасибо, но не обижаюсь.
Продолжу, аналогию с велосипедом. Прежде чем разгоняться до любой скорости, следует подумать: успеваем ли рулить, как будем останавливаться.
Спасибо за дополнение.
«сбор статистики вашего приложения» — так понял, имели ввиду профилирование (profiling), т.е. контроль производительности.
Я для этих целей, настраиваю вывод лога в CSV. Загружаю его в Calc (Excel). Настраиваю фильтры на интересующую операцию. Далее, добавляю колонку, которая вычисляет разницу времени вывода сообщения.
Дальше, по обстоятельствам. Но обычно, можно отыскать в каком окружении код начинает резко медленнее работать.
Собственно она там и есть. Я ссылку на исходный код класса привел.
Необоснованно пока, но предположу, что данном случае методы должны подставляться при jit-копиляции. (что тоже упомянуто)
Поэтому, предпроверка просто бессмысленна.
Но все же, пока не дописал бенчмарки, развивать бы эту тему не стал.
Я обычно для этих целей использую субрепозитории в Mercurial или Git.
Каждая подключаемая библиотека вервионируется в своем репо, который подключается к проекту- потребителю.
Смена версии библиотеки, при этом, это отдельный коммит с тестированием.
Для определения того, что водитель действительно хочет перестроиться достаточно должно быть включенных поворотников. И это кстати, хороший способ ненавязчиво напомнить о том, что их надо включать. ;)
Кроме того, как себя помню, все это должно хорошо помогать начинающим водителям.
Спасибо за исходники. Попробую и себе делать…
Вот такой код на моей машине выполняется примерно 10 секунд (визуально и по системным часам).
Код замера интервала времени выполнения эквивалентен опубликованному.
Код логирования будет работать чуть быстрее чем в NLog за счет статических членов.
Продолжу, аналогию с велосипедом. Прежде чем разгоняться до любой скорости, следует подумать: успеваем ли рулить, как будем останавливаться.
И вывод как раз в том, что столько все равно не обработаешь.
Ну поиск же есть! Вот эта статья.
Но вообще, на Хабре удивление мало написано. А интересных подробностей по теме много…
На Мембране можно почитать описание «прорыва» технологии.
На Noname'е интересна более общая статья про сам процесс исследования.
А теперь мигом к семье! Завтра отпишетесь. :-D
«сбор статистики вашего приложения» — так понял, имели ввиду профилирование (profiling), т.е. контроль производительности.
Я для этих целей, настраиваю вывод лога в CSV. Загружаю его в Calc (Excel). Настраиваю фильтры на интересующую операцию. Далее, добавляю колонку, которая вычисляет разницу времени вывода сообщения.
Дальше, по обстоятельствам. Но обычно, можно отыскать в каком окружении код начинает резко медленнее работать.
Необоснованно пока, но предположу, что данном случае методы должны подставляться при jit-копиляции. (что тоже упомянуто)
Поэтому, предпроверка просто бессмысленна.
Но все же, пока не дописал бенчмарки, развивать бы эту тему не стал.