Очень трудно заставить себя читать дальше, когда автор начинает с вранья. В 17 лет я работал и учился около 20 часов в сутки: ходил в школу, домашние задания делал на переменах, а по ночам руководил некоммерческой организацией.
Привет! Я пока ещё не полностью прочитал статью, но у меня уже появился вопрос: почему использовался такой хитрый способ дёрнуть rdtsc? Сейчас у меня только догадки: 1) Неужели родной Stopwatch даёт столь большие накладные расходы, что эта пляска с бубном того стоила? 2) Может быть были опасения, что SW задействует HPET?
По тому, что успел прочитать сложилось впечатление, что ты не совсем правильно понимашь, что именно он там считает. В статье надо бы уточнение добавить. В интеловском мануале, помнится, довольно чётко написано, как именно он работает. Когда я с ним экспериментировал, лет 5 назад, у меня 2 (почти) последовательных вызова RDTSC иногда приводили к нулевой стоимости кода. Тогда я пришёл к выводу, что после вызова надо ставить Full Fence - иначе короткие интевалы не очень мерять получается.
Странно. Я по контексту догадался: рефакторинг и раскапывание внутренностей чего-нибудь типа EF - это явно не на 20 минут, и ведёт к проблемам с пищеварением.
Кто, абстрактный класс? Он его не реализует. А вот реализуют ли его наследники финализатор я знать не могу: это вопрос к тому, кто его будет имплементить, или уже заимплементил. Однако в моём случае он ссылается на PatternLayout, который тоже не SafeHandle.
Угу, только чаще всего для логирования используют что-нибудь вроде log4net, а для логирования пишут что-то типа Logger.Warn(«object not disposed»).
А логгер этот не простой, а «золотой» — использует
abstract class LoggerWrapperImpl {}
в качестве таргета для строчек лога. Это нифига не наследник SafeHandle — вполне может уже прибит в момент работы финализатора.
Это черевато непредсказуемыми падениями: порядок вызова финализаторов недетерминирован, равно как и порядок убийства объектов. Закрываешь окно приложения, а оно тебе НА! CurrentDomain_UnhandledException.
Чтобы гарантировать, что Dispose() таки вызвали, нужно тесты писать.
Это не проблема фрэймворка — это проблема кода приложения. Многие фрэймворки требуют обращения к UI'ным объектам только в UI'ном потоке, просто потому что STAThread — тяжкое наследие COM'а. Во многих фрэймворках и библиотеках есть Invoke() и BeginInvoke()
Тут даже не про тонкую оптимизацию речь. Такие знания наиболее полезны, когда от пользователей повалили дампы с жалобами на «повисшую» софтиную. Раскопать, кто же наинвочил в UI'ный поток, без знания о сборке мусора практически невозможно, особенно если QA не может воспроизвести проблему, а напрямую отдебажить не представляется возможным ввиду объёма кода и кол-ва потоков.
>Но мне сложенее всего понять, как можно играть в шутер на мобилке! Во-первых, управление: при самом продуманном варианте все это выглядит каким-то страданием до чувства отвращения. Во-вторых, размер дисплея.
Ага, поддерживаю.
Я когда-то плотно в Q3 Arena играл. В свете этого, шутер на мобилке для меня — что-то вроде параолимпиады, т.е. соревнования инвалидов-колясочников по бегу на дистанции с препятствиями. Там, где игрок с мышкой и клавиатурой делает 2 прицеливания в секунду (во время движения смещает точку прицела), инвалид на пацьцетыкательном девайсе пытается пройти из точки А в точку Б.
Для неверующих вот тут, с 38-й секунды показано как это делается (2 и больше прицельных выстрела в секунду) youtu.be/cRV0tclxXMQ
>А как это делается, извините? Ну вот представьте себе: вы закрыли таску «добавить иконку в профиль пользователя». А через неделю открыли другую «в сводной таблице нет информации и количестве покупателей, купивших товар».
Не, не так. У нас взмах крыла бабочки к взрыву сверхновой не приводит. Такие таски чаще всего переоткрываются с «у части пользователей неверная иконка, или её нет», или «в логах NullReferenceException». Происходит это потому, что иконки/картинки/подсказки часто зависят от локали пользователя или от его организации. Т.е., например, в базовой версии c культурой en-us всё хорошо, а в кастомизированной с испанской локалью — нет. Или «шаг вперёд — шаг назад иконка пропадает».
Десять тасков, где 9 — следствие криво закрытой первой, — это неверный подход. Правильный подход — переоткрывать таску до тех пор, либо пока фича не будет работать, либо пока нерадивого «менеджера» не уволят.
У нас переоткрывают. Логика простая: высокому начальству не интересно сколько тасок закрыто. Интересно какие фичи реализованы, и что пойдёт в текущий релиз (например, что будет в release notes).
>javascript язык с динамическими типами, по этому надо всегда понимать какая сигнатура метода будет вызывана и с какими аргументами…
ужс!
Я уже настолько привык, что такие вещи мне помогает контролировать компилятор, что сейчас для меня это уже дико.
У нас туда даже пройдя ревью, и цепкие лапы QA к клиентам баги попадают, а если ещё и вот такое стрелять будет… Нет, спасибо: в жизни и так достаточно сложностей, а моё внимание и память не безграничны. И вообще, в отличие от языков курильщика, компилятор здорового человека не позволяет себе ногу отстрелить, по крайней мере не таким примитивным способом.
Я вот об этом:
static void Main(string[] args)
{
//WARNING - CS0642 : Возможно ошибочный пустой оператор
for (long i = 0; i < int.MaxValue; i++);{}
double a, b, c; //WARNING -CS0168
a = b = 1; //WARNING - CS0219
var dsf = new int[] {1, 2, 3};
//ERROR CS1661: Невозможно преобразовать "лямбда-выражение" к типу делегата "System.Func<int,int,double>",
//поскольку типы параметров не совпадают с типами параметров делегата
//ERROR CS1661: Невозможно преобразовать "лямбда-выражение" к типу делегата "System.Func<int,int,double>",
//поскольку типы параметров не совпадают с типами параметров делегата
Enumerable.Select<int, double>( dsf, ( double p1, double p2) => { return p1 * p2;});
}
В штатах официальные СЦ тоже далеко не всегда в пешей доступности. Основная же проблема тут в том, что мелочный ремонт у них часто стоит как новый ноут.
Мой опыт подсказывает, что наоборот. Пока у меня была возможность играться, я едва-едва сводил концы с концами. Только потом захотелось своё жильё и немного больше уверенности в завтрашнем дне — необходимость впахивать стала осознанной. А неудачная попытка уйти в свободное плаванье показала, что «свобода» может быть хуже рабства.
>>Некоторые совсем сильные парни пишут в vim, говорят там есть плагины со всем что может понадобиться.
Писать даже я могу в блокноте, даже в командной строке. И компилировать из под неё же. Сложности начинаются, когда нужно раскопать багу и поправить багу в мегатонне говнокода, доставшегося в наследство. Для этого нужны продвинутые возможности навигации по коду, статический анализатор (который, например, подскажет, что «override» забыли), и хорошие возможности для рефакторинга.
Очень трудно заставить себя читать дальше, когда автор начинает с вранья.
В 17 лет я работал и учился около 20 часов в сутки: ходил в школу, домашние задания делал на переменах, а по ночам руководил некоммерческой организацией.Привет!
Я пока ещё не полностью прочитал статью, но у меня уже появился вопрос: почему использовался такой хитрый способ дёрнуть rdtsc?
Сейчас у меня только догадки:
1) Неужели родной Stopwatch даёт столь большие накладные расходы, что эта пляска с бубном того стоила?
2) Может быть были опасения, что SW задействует HPET?
По тому, что успел прочитать сложилось впечатление, что ты не совсем правильно понимашь, что именно он там считает. В статье надо бы уточнение добавить. В интеловском мануале, помнится, довольно чётко написано, как именно он работает. Когда я с ним экспериментировал, лет 5 назад, у меня 2 (почти) последовательных вызова RDTSC иногда приводили к нулевой стоимости кода. Тогда я пришёл к выводу, что после вызова надо ставить Full Fence - иначе короткие интевалы не очень мерять получается.
Странно. Я по контексту догадался: рефакторинг и раскапывание внутренностей чего-нибудь типа EF - это явно не на 20 минут, и ведёт к проблемам с пищеварением.
Сериалы :(
Тут есть люди, у которых маленькие дети и они не посмотрели ни одного фильнма за последние 4 года.
А логгер этот не простой, а «золотой» — использует
abstract class LoggerWrapperImpl {}
в качестве таргета для строчек лога. Это нифига не наследник SafeHandle — вполне может уже прибит в момент работы финализатора.
Чтобы гарантировать, что Dispose() таки вызвали, нужно тесты писать.
Ага, поддерживаю.
Я когда-то плотно в Q3 Arena играл. В свете этого, шутер на мобилке для меня — что-то вроде параолимпиады, т.е. соревнования инвалидов-колясочников по бегу на дистанции с препятствиями. Там, где игрок с мышкой и клавиатурой делает 2 прицеливания в секунду (во время движения смещает точку прицела), инвалид на пацьцетыкательном девайсе пытается пройти из точки А в точку Б.
Для неверующих вот тут, с 38-й секунды показано как это делается (2 и больше прицельных выстрела в секунду) youtu.be/cRV0tclxXMQ
Не, не так. У нас взмах крыла бабочки к взрыву сверхновой не приводит. Такие таски чаще всего переоткрываются с «у части пользователей неверная иконка, или её нет», или «в логах NullReferenceException». Происходит это потому, что иконки/картинки/подсказки часто зависят от локали пользователя или от его организации. Т.е., например, в базовой версии c культурой en-us всё хорошо, а в кастомизированной с испанской локалью — нет. Или «шаг вперёд — шаг назад иконка пропадает».
У нас переоткрывают. Логика простая: высокому начальству не интересно сколько тасок закрыто. Интересно какие фичи реализованы, и что пойдёт в текущий релиз (например, что будет в release notes).
Количество тасок — это очковтирательство.
ужс!
Я уже настолько привык, что такие вещи мне помогает контролировать компилятор, что сейчас для меня это уже дико.
У нас туда даже пройдя ревью, и цепкие лапы QA к клиентам баги попадают, а если ещё и вот такое стрелять будет… Нет, спасибо: в жизни и так достаточно сложностей, а моё внимание и память не безграничны. И вообще, в отличие от языков курильщика, компилятор здорового человека не позволяет себе ногу отстрелить, по крайней мере не таким примитивным способом.
Я вот об этом:
Кстати, под какой именно лицензией оно там?
Писать даже я могу в блокноте, даже в командной строке. И компилировать из под неё же. Сложности начинаются, когда нужно раскопать багу и поправить багу в мегатонне говнокода, доставшегося в наследство. Для этого нужны продвинутые возможности навигации по коду, статический анализатор (который, например, подскажет, что «override» забыли), и хорошие возможности для рефакторинга.