Ну почитать можно всякого разного, лучше видео посмотреть. Я вот на своем личном опыте говорю, что все работает отлично (не из серии сам не пробовал, но мне рассказывали)
С того же сайта:
«iOS 10 beta 2 добавит вашим iPhone более двух часов автономной работы»
Практически любой влажной салфеткой для протирки рук, или любым другим спирто-содержащим веществом, например, спрей для экранов мониторов или телевизоров которыми по ошибке протирают экраны гаджетов (для смартфонов есть специальные спреи без спирта)
Вот тут можете сами убедиться, что вопреки распространенному мнению, ios 9 не замедляли, а ускоряли. Поэтому замечание Fezzo может и верное, но не относится к ios
Работает с минимальной разницей, ни о каких тормозах или «искусственном замедлении» речи не идет. В некоторых местах ios 9 даже быстрее (например, app store запускается ощутимо быстрее, скроллинг в браузере более отзывчивый) При этом есть легкий способ еще увеличить скорость, просто отключив анимации сворачивания/разворачивания (вместо них будет эффект fadein)
То что там говорят устарело как минимум на пол года, я говорю про последнюю ios 9.3.2
Был у ios 9 период когда она начала работать хуже чем ios8, но потом это исправили
«Результаты эксперимента могут порадовать пользователей, которые ждут улучшения производительности в iOS 9.3. Финальная версия ОС может похвастаться более высоким быстродействием. В частности, исследователь обращает внимание на минимальные задержки перед запуском приложений. Улучшения заметны как на iPhone 4s, так и на iPhone 5, а также более новых моделях.»
Про ios не надо, iphone 5 (которому почти 4 года уже) прекрасно себя чувствует на официальной ios 9 (и судя по 2 бете ios10 и на ios10 будет отлично), все летает и работает очень стабильно, постоянно приходится тестировать на 5 айфоне разное, поэтому знаю о чем говорю
Дело не в принудительном сглаживании, если к таким огромным кубикам применить сглаживание, то лучше не станет, так как будет либо тоже самое, либо мыло
Реклама не реклама, но обозревает правильный вопрос. На андроиде покупая самое топовое и дорогое устройство можно не получить топовые характеристики и юзер экспириенс
Сам удивился тому, купив недорогой xiaomi redmi 2, что у него было очень хорошее олеофобное покрытие (которое я случайно стер влажной салфеткой), или то что игры реально плохо выглядят на топовых самсунгах, хотя экраны с виду очень хорошие, а железо по цифрам бьет все рекорды
Стоят на серверах контроллеры что-то вроде DELL H700, всегда их отключаю и переключаюсь на софтовый mdadm
Причина в том, что хардвартный контроллер на 4х дисках не может прокачать гигабитный канал, где-то уже на 750-800 мбит/с диски утилизируются на 100%
Подключая 4 диска в raid1 через mdadm получается в плане чтения не честный raid1, а чтение с дисков по очереди (round-robin), то есть в итоге распределяется равномерно (±) нагрузка по всем 4м дискам
Таким образом запросто удается прокачать весь гигабит (3 диска уже не справляются) и даже запас остаётся (к минусам долгое время ресинхронизации после сбора массива или замены вышедшего из строя диска)
Ну хотя бы потому что это удобно. Не всем нужен кластер на 100500 серверов или вообще кластер, а вот schema-less явно удобно, еще удобно взять данные из базы в виде json, этот же json тут же отдать шаблонизатору без каких-либо промежуточных действий
Я вот хоть не java-разработчик, но было что-то похожее на php 7.0, перепробовал множество настроек, это не помогло (оно и понятно, до этого работало, после апгрейда перестало)
Не знаю помогло бы мне, будь я java-разработчиком, но временно пришлось отключить opcache
В итоге спустя пару php сборок это исправили и включил обратно
Всё чаще прихожу к такому же мнению. Не то что быстрее vdom, а то что не такой уж и медленный
Допустим, многих устраивает скорость react, тогда если взять тот же тест http://mathieuancelin.github.io/js-repaint-perfs/
react ~30-32fps
native dom ~24-26fps
Optimized react ~35-38fps
Optimized native dom ~39-42fps
Тоесть, как минимум видно что и dom в целом может быть быстрее
Конечно это если не сравнивать с каким нибудь vidom, который выдает ~80-110fps, и если выбор именно какой vdom, то стоит однозначно попробовать Vidom
function f(o) {
let r = '';
for(let key in o) {
r += `${key} = ${o[key]}\n`;
}
return r;
}
// определяем рабочую переменную
let temp = {};
let result = [];
//первый набор данных
temp = {x:0, y:1};
//шаблонная работа с набором данных
result.push(f(temp));
//второй набор данных
temp = {a:1, b:2}
//шаблонная работа с набором данных
result.push(f(temp));
//и так далее, много разных наборов
Данные разные, но работа с ними примерно одинакова. Например, в jade, при определенном сценарии использования, по сути что-то такое и есть, когда на входе данные с атрибутами, а на выходе сформированная html строка
Получается, пока атрибуты примерно одинаковые (всегда только class или href), то всё работает быстро, как только начали в шаблонизатор попадать разнообразные атрибуты (хотя бы 1 раз на тысячу вызовов), f() переходит рано или поздно в «мегаморфизм» и оптимизации будут минимальны
И допустим, чтобы оставаться быстрым для стандартных случаев, уже нужно самим вводить вручную фильтрацию на атрибуты — если какой-то стандартный набор, то вызываем f1(), если что-то новенькое то f2(), если сходу видно что что-то экзотическое (допустим attributes.lenght > 5), то вообще f3(). При этом, естественно, f1(), f2(), f3() будут одинаковыми
Используйте https://www.adminer.org/ (один файл, легковестный, во многом удобнее)
Что с myqsl, что с postgresql (и другими базами) работа в итоге будет одинаковой
Для Int на той же таблице по сути разницы нет:
Просто OFFSET: Execution time: 202.323 ms
Вариант с WITH: Execution time: 138.158 ms
Вариант с JOIN: Execution time: 133.200 ms
explain
postgres=# EXPLAIN ANALYZE WITH temp_rows AS (
SELECT n
FROM medley
ORDER BY n OFFSET 500000
LIMIT 30
)
SELECT * FROM medley WHERE medley.n = ANY(ARRAY(SELECT n FROM temp_rows)::Int[]);
QUERY PLAN
-------------------------------------------------------------------------------------------------------------------------------------------------------------
Index Scan using n_idx on medley (cost=12986.44..13034.53 rows=10 width=38) (actual time=138.009..138.107 rows=30 loops=1)
Index Cond: (n = ANY ($1))
CTE temp_rows
-> Limit (cost=12984.63..12985.41 rows=30 width=4) (actual time=137.945..137.953 rows=30 loops=1)
-> Index Only Scan using n_idx on medley medley_1 (cost=0.43..259694.04 rows=10000374 width=4) (actual time=0.038..110.982 rows=500030 loops=1)
Heap Fetches: 0
InitPlan 2 (returns $1)
-> CTE Scan on temp_rows (cost=0.00..0.60 rows=30 width=4) (actual time=137.950..137.968 rows=30 loops=1)
Planning time: 0.219 ms
Execution time: 138.158 ms
(10 rows)
Решил так же проверить, как этот вариант будет вести для более частых малых OFFFSET (5000, например), тут уже вариант с WITH стал сильно отставать
Результаты для OFFSET 5000 LIMIT 30:
Просто OFFSET: Execution time: 3.380 ms
Вариант с WITH: Execution time: 8.379 ms
Вариант с JOIN: Execution time: 1.788 ms
С того же сайта:
«iOS 10 beta 2 добавит вашим iPhone более двух часов автономной работы»
iOS 8.4.1 vs iOS 9.3.2
https://youtu.be/Pmj6lHODdOc
Работает с минимальной разницей, ни о каких тормозах или «искусственном замедлении» речи не идет. В некоторых местах ios 9 даже быстрее (например, app store запускается ощутимо быстрее, скроллинг в браузере более отзывчивый)
При этом есть легкий способ еще увеличить скорость, просто отключив анимации сворачивания/разворачивания (вместо них будет эффект fadein)
Был у ios 9 период когда она начала работать хуже чем ios8, но потом это исправили
«Результаты эксперимента могут порадовать пользователей, которые ждут улучшения производительности в iOS 9.3. Финальная версия ОС может похвастаться более высоким быстродействием. В частности, исследователь обращает внимание на минимальные задержки перед запуском приложений. Улучшения заметны как на iPhone 4s, так и на iPhone 5, а также более новых моделях.»
Сам удивился тому, купив недорогой xiaomi redmi 2, что у него было очень хорошее олеофобное покрытие (которое я случайно стер влажной салфеткой), или то что игры реально плохо выглядят на топовых самсунгах, хотя экраны с виду очень хорошие, а железо по цифрам бьет все рекорды
Причина в том, что хардвартный контроллер на 4х дисках не может прокачать гигабитный канал, где-то уже на 750-800 мбит/с диски утилизируются на 100%
Подключая 4 диска в raid1 через mdadm получается в плане чтения не честный raid1, а чтение с дисков по очереди (round-robin), то есть в итоге распределяется равномерно (±) нагрузка по всем 4м дискам
Таким образом запросто удается прокачать весь гигабит (3 диска уже не справляются) и даже запас остаётся (к минусам долгое время ресинхронизации после сбора массива или замены вышедшего из строя диска)
https://github.com/WebAssembly/design/blob/master/GC.md
Не понятно о каких костылях идет речь, формат бинарный, можно строить любые индексы по любому полю в json и т.д.
Помимо schema-less остаются плюсы реляционной таблицы
https://market.yandex.ru/catalog/54545/list?hid=6427100&hid=6427100&in-stock=0
навигация по страницам или «Показать еще». При этом «показать еще» меняет и адресс страницы, тоесть случайный рефреш или мисс-клик не сломает просмотр
Не знаю помогло бы мне, будь я java-разработчиком, но временно пришлось отключить opcache
В итоге спустя пару php сборок это исправили и включил обратно
Допустим, многих устраивает скорость react, тогда если взять тот же тест http://mathieuancelin.github.io/js-repaint-perfs/
react ~30-32fps
native dom ~24-26fps
Optimized react ~35-38fps
Optimized native dom ~39-42fps
Тоесть, как минимум видно что и dom в целом может быть быстрее
Конечно это если не сравнивать с каким нибудь vidom, который выдает ~80-110fps, и если выбор именно какой vdom, то стоит однозначно попробовать Vidom
https://github.com/nolimits4web/framework7/issues
http://forum.framework7.io/#!/bugs-and-issues
Подобные баги обычно легко исправляются
Данные разные, но работа с ними примерно одинакова. Например, в jade, при определенном сценарии использования, по сути что-то такое и есть, когда на входе данные с атрибутами, а на выходе сформированная html строка
Получается, пока атрибуты примерно одинаковые (всегда только class или href), то всё работает быстро, как только начали в шаблонизатор попадать разнообразные атрибуты (хотя бы 1 раз на тысячу вызовов), f() переходит рано или поздно в «мегаморфизм» и оптимизации будут минимальны
И допустим, чтобы оставаться быстрым для стандартных случаев, уже нужно самим вводить вручную фильтрацию на атрибуты — если какой-то стандартный набор, то вызываем f1(), если что-то новенькое то f2(), если сходу видно что что-то экзотическое (допустим attributes.lenght > 5), то вообще f3(). При этом, естественно, f1(), f2(), f3() будут одинаковыми
Что-то в этом духе или это бессмысленно?
Что с myqsl, что с postgresql (и другими базами) работа в итоге будет одинаковой
Просто OFFSET: Execution time: 202.323 ms
Вариант с WITH: Execution time: 138.158 ms
Вариант с JOIN: Execution time: 133.200 ms
Решил так же проверить, как этот вариант будет вести для более частых малых OFFFSET (5000, например), тут уже вариант с WITH стал сильно отставать
Результаты для OFFSET 5000 LIMIT 30:
Просто OFFSET: Execution time: 3.380 ms
Вариант с WITH: Execution time: 8.379 ms
Вариант с JOIN: Execution time: 1.788 ms