Когда у вас много параллельных чтений, нагрузка распределяется сама собой и никакого выигрыша от предложенной в статье «асинхронности» не будет. А когда читаете в один поток, разница будет зависеть от времени обработки — чем больше время обработки, тем больше разница, но не более, чем в два раза. Если вы читаете и пишете одновременно, разница будет до 4 раз.
Одинаковые, потому что уверен, что они не ставили разные версии для тестирования =) Замеры на базе в 200 метров, а в предисловии про терабайтные базы — думаю, что разные версии серверов не такой забавный челлендж будет, как проблема локальности, когда продукт конкурентов перестанет отставать =)
Про сравнение массивов — они просто в начале пути, я полагаю =) Про понимать — это нужно обычно везде ;)
Предположу, что потому что версии SQL Server одинаковые, они одинаково обрабатывают входящие данные.
Генератор случайных чисел, который выдаёт неслучайные числа, это не ошибка реализации, это так задумано было, чтобы можно было повторить.
Я тоже полагаю, что сравнение двух массивов байтов перед сравнением XML даст огромный прирост производительности. Если не даст, надо делать какие-то трюки и всё равно приходить к тому, чтобы сравнивать не XML, а что-то попроще.
Эта статья про то, как одни безрукие программисты тягались с другими безрукими программистами, тем не менее, я считаю, что спор про сравнение массивов вы проиграли =)
Вот-вот. Всего лишь сотни и тысячи запросов.
Вместо десятков тысяч на MongoDB, например.
Конкатенация раз в 50-100 примерно быстрее форматной строки для записи в журнал.
А если писать в журнал сразу байтики, без конкатенации, то будет быстрее в 1000 раз, чем с конкатенацией =)
Чтобы не писать бреда, который вы написали, надо получить опыт, а не прочитать где-то про плохую раннюю оптимизацию. С опытом приходит тайное знание, где оптимизация нужна, а где можно отложить на потом и доработать профайлером.
Самый быстрый способ работы с файлами это memory mapping.
Readahead, например, из вашего рассказа, это магия, недоступная простым смертным. Эту прекрасную неотключаемую «фичу» в ядре Линукса мы обычно закручиваем до минимума, потому что она упарывает производительность БД на ровном месте.
Когда поработаете с десятками гигабайтов данных, почувствуете «эффективность» и остальных перечисленных «фич». Статья про максимальную производительность, а не про лабораторные работы в школе.
Удивительно видеть производителя, потерявшего всё с таким странным подходом. Оформленный предзаказ пришёл уведомлением об оформлении через несколько недель, когда я про него уже забыл. Это когда опрос где-то размещали. Продаваться на сайте Нокии телефоны стали через неделю после продажи везде. Цветных телефонов нигде нет, только чёрные и белые.
Считаю, что отбивая интерес у самых желающих, ничего, кроме закрытия, компанию не ждёт. Пойду смотреть, что за телефоны на WP8 у Самсунга, он любит копировать дизайн, может дизайн N9 тоже использовал «для вдохновления» =)
Капс в меню не нравится.
Использование везде (таб активного документа, «вернуться» и «открыть») синего цвета вместо серого лучше не делает, оставили бы серый. Свои цвета должны быть у кнопок, чтобы они отличались, если их красить в синий, они сливаются всё равно, а из-за ужасного цвета оттенка ещё и раздражают глаза.
Забыли упомянуть ещё одну важную и очень бурную область, телефоны.
Там тоже всё просто уже. Во всяком случае, для современных операционок Microsoft, Apple и Google.
Сложные переносы блоков я не буду исследовать через окно коммита. По большому счёту, перед коммитом проводится последняя инспекция на предмет «а не забыли ли мы скальпель у пациента внутри?»
Просто я считаю, что кодить без коммита много дней вредно для здоровья, поэтому в пределах любого большого рефакторинга будет несколько коммитов с максимальным интервалом в несколько часов.
Когда мы только перешли на Subversion, я с трудом понимал эти плюсики. Но взаимодействие с миром open source, где не работает абсолютно всё, научило с ними спокойно обходиться. К примеру, только в первую неделю знакомства с MongoDB было отправлено пяток патчей разработчикам и клиента, и сервера.
А посмотреть большой дифф в отдельном окне можно и в TortoiseHG, это делается всё тем же даблкликом по файлу или правый клик -> левый клик. Вы в одном из комментариев выше были за возможность выбора =) Вот TortoiseHG эту возможность и предоставляет.
Это не только к окну коммита относится. Check modifications должно работать аналогично, там тоже список файлов на потенциальный коммит. Я писал только про окно коммита, потому что часто им пользуюсь вместо Check modifications — не надо лезть в подменю, если в проводнике, плюс в VS хоткей биндится на коммит.
А вменяемым он станет сразу, как только для дифа не будет нового окна. Тогда не придётся никому запоминать, как работает даблклик в списке файлов, летать про клавиатуре или с мышки на клавиатуру и обратно. А если ещё и диф при этом будет показывать только изменения, то совсем хорошо. Использовать в этом месте «большой» диф со всем кодом и его изменениями мне кажется мешающей избыточностью.
Вы случайно не родственник товарищу, который мне выше раз 7 написал, что я чего-то не понимаю из детского мануала к Mercurial или TortoiseHG? Вроде написали про желание понять причину моего заявления, а не про повышение самооценки за мой счёт. Надеюсь, я достаточно внятно выразился, что «не можете запомнить», «не понимаете» и прочие подростковые способы ведения диалога его закончат.
Начался наш диалог с мышки. Поэтому я и привёл примером паттерн работы только с мышкой. Упоминание стрелок исказило картину =)
В зависимости от ситуации я использую стрелки или не использую — зависимость не исследовал, потому что на автомате действую. Предположу, что зависит от активного контрола, от действий в окне дифа и количества файлов. Если фокус в окне дифа, стрелки будут крутить его, а не идти по списку с файлами, поэтому от клика иногда не уйдёшь. Но в любом случае мышка остаётся в руке, потому что колесом крутится окно с дифом. Стрелки жмутся левой рукой.
Что имеем с SVN/Git. Использование с мышкой описал раньше. Если использовать Enter/стрелки и Esc, надо правую руку убирать с мышки на Enter/стрелки и листать клавиатурой. Потому что левая рука на Esc, потому что летать по клавиатуре левой рукой и/или правой рукой мышка<->клавиатура неудобно. Листание клавиатурой дискомфортное, потому что нет плавности и приходится напрягаться.
При любом раскладе в SVN/Git либо активный пиксельхантинг, либо в глазах рябит из-за листания клавиатурой.
И ещё про «запомнить»: «Знание нескольких принципов освобождает от знания многих фактов». Используя это правило можно не забивать голову мусором, выбирая правильно реализованные инструменты. Пользоваться неправильно (или непривычно) реализованными инструментами это мешает, ясное дело, но в целом по жизни так эффективнее. Из-за редкого столкновения с отсутсвием единообразия поведения запомнить место его проявления не довелось.
Как в TortoiseHG, одним левым кликом по файлу с возможностью листания клавиатурой.
А не правый клик -> левый клик -> левый клик (закрыть окно).
Ещё можно даблкликом воспользоваться, но он не везде работает одинаково (в некоторых окнах открывает не дифф, а файл на редактирование), поэтому заставляет задумываться, можно ли даблкликать или надо правым кликом и потом из меню левым.
А, с таким я никогда не сталкивался =) У меня все проекты гомогенные. А даже если бы и были гетерогенными, то пользовался бы встроенными в HG средствами для работы с внешними репозиториями на SVN. В таком случае офлайн-фича Mercurial никуда не теряется из-за одного проекта на Subversion.
Если в проекте очень длинная история, импортировать можно не всю, а какую-то относительно свежую часть шапки. Иногда промахиваешься с глубиной, но так лучше, чем без истории вообще или с двухдневным ожиданием импорта.
А какая версия? У меня 1.7.7, параллельно с HgScc работает нормально.
Они убрали 1.7.7 из даунлоада, чтобы народ покупал новую версию для десятой студии. Я раздумывал на тему апгрейда, но в двойке для меня кроме иконок ничего не поменялось.
Про сравнение массивов — они просто в начале пути, я полагаю =) Про понимать — это нужно обычно везде ;)
Генератор случайных чисел, который выдаёт неслучайные числа, это не ошибка реализации, это так задумано было, чтобы можно было повторить.
Я тоже полагаю, что сравнение двух массивов байтов перед сравнением XML даст огромный прирост производительности. Если не даст, надо делать какие-то трюки и всё равно приходить к тому, чтобы сравнивать не XML, а что-то попроще.
Эта статья про то, как одни безрукие программисты тягались с другими безрукими программистами, тем не менее, я считаю, что спор про сравнение массивов вы проиграли =)
Вместо десятков тысяч на MongoDB, например.
Конкатенация раз в 50-100 примерно быстрее форматной строки для записи в журнал.
А если писать в журнал сразу байтики, без конкатенации, то будет быстрее в 1000 раз, чем с конкатенацией =)
Чтобы не писать бреда, который вы написали, надо получить опыт, а не прочитать где-то про плохую раннюю оптимизацию. С опытом приходит тайное знание, где оптимизация нужна, а где можно отложить на потом и доработать профайлером.
Readahead, например, из вашего рассказа, это магия, недоступная простым смертным. Эту прекрасную неотключаемую «фичу» в ядре Линукса мы обычно закручиваем до минимума, потому что она упарывает производительность БД на ровном месте.
Когда поработаете с десятками гигабайтов данных, почувствуете «эффективность» и остальных перечисленных «фич». Статья про максимальную производительность, а не про лабораторные работы в школе.
Считаю, что отбивая интерес у самых желающих, ничего, кроме закрытия, компанию не ждёт. Пойду смотреть, что за телефоны на WP8 у Самсунга, он любит копировать дизайн, может дизайн N9 тоже использовал «для вдохновления» =)
Но какая разница, их всё равно не продают.
Использование везде (таб активного документа, «вернуться» и «открыть») синего цвета вместо серого лучше не делает, оставили бы серый. Свои цвета должны быть у кнопок, чтобы они отличались, если их красить в синий, они сливаются всё равно, а из-за ужасного цвета оттенка ещё и раздражают глаза.
Там тоже всё просто уже. Во всяком случае, для современных операционок Microsoft, Apple и Google.
Просто я считаю, что кодить без коммита много дней вредно для здоровья, поэтому в пределах любого большого рефакторинга будет несколько коммитов с максимальным интервалом в несколько часов.
Когда мы только перешли на Subversion, я с трудом понимал эти плюсики. Но взаимодействие с миром open source, где не работает абсолютно всё, научило с ними спокойно обходиться. К примеру, только в первую неделю знакомства с MongoDB было отправлено пяток патчей разработчикам и клиента, и сервера.
А посмотреть большой дифф в отдельном окне можно и в TortoiseHG, это делается всё тем же даблкликом по файлу или правый клик -> левый клик. Вы в одном из комментариев выше были за возможность выбора =) Вот TortoiseHG эту возможность и предоставляет.
А вменяемым он станет сразу, как только для дифа не будет нового окна. Тогда не придётся никому запоминать, как работает даблклик в списке файлов, летать про клавиатуре или с мышки на клавиатуру и обратно. А если ещё и диф при этом будет показывать только изменения, то совсем хорошо. Использовать в этом месте «большой» диф со всем кодом и его изменениями мне кажется мешающей избыточностью.
Начался наш диалог с мышки. Поэтому я и привёл примером паттерн работы только с мышкой. Упоминание стрелок исказило картину =)
В зависимости от ситуации я использую стрелки или не использую — зависимость не исследовал, потому что на автомате действую. Предположу, что зависит от активного контрола, от действий в окне дифа и количества файлов. Если фокус в окне дифа, стрелки будут крутить его, а не идти по списку с файлами, поэтому от клика иногда не уйдёшь. Но в любом случае мышка остаётся в руке, потому что колесом крутится окно с дифом. Стрелки жмутся левой рукой.
Что имеем с SVN/Git. Использование с мышкой описал раньше. Если использовать Enter/стрелки и Esc, надо правую руку убирать с мышки на Enter/стрелки и листать клавиатурой. Потому что левая рука на Esc, потому что летать по клавиатуре левой рукой и/или правой рукой мышка<->клавиатура неудобно. Листание клавиатурой дискомфортное, потому что нет плавности и приходится напрягаться.
При любом раскладе в SVN/Git либо активный пиксельхантинг, либо в глазах рябит из-за листания клавиатурой.
И ещё про «запомнить»: «Знание нескольких принципов освобождает от знания многих фактов». Используя это правило можно не забивать голову мусором, выбирая правильно реализованные инструменты. Пользоваться неправильно (или непривычно) реализованными инструментами это мешает, ясное дело, но в целом по жизни так эффективнее. Из-за редкого столкновения с отсутсвием единообразия поведения запомнить место его проявления не довелось.
А не правый клик -> левый клик -> левый клик (закрыть окно).
Ещё можно даблкликом воспользоваться, но он не везде работает одинаково (в некоторых окнах открывает не дифф, а файл на редактирование), поэтому заставляет задумываться, можно ли даблкликать или надо правым кликом и потом из меню левым.
Если в проекте очень длинная история, импортировать можно не всю, а какую-то относительно свежую часть шапки. Иногда промахиваешься с глубиной, но так лучше, чем без истории вообще или с двухдневным ожиданием импорта.
Коммит без просмотра диффов разумно делать только для очень коротких изменений.
TortoiseSVN лучше остальных и с ним работает плагин VisualSVN. То, что всё остальное ещё хуже не значит, что TortoiseSVN предел мечтаний.
Они убрали 1.7.7 из даунлоада, чтобы народ покупал новую версию для десятой студии. Я раздумывал на тему апгрейда, но в двойке для меня кроме иконок ничего не поменялось.
Я не один такой уникальный, кто смотрит диффы при коммите, судя по TortoiseHG.