AnglarJS это здорово! Но при работе с большими списками, содержащими сложной структуры данных, он может начать работать очень медленно! Мы столкнулись с этой проблемой при переносе нашей административной панели на AngularJS. Она должна была работать без задержек при отображении около 500 строк. Но на первое отображение уходило до 7 секунд. Ужасно!
Мы обнаружили два узких места в нашей реализации. Одно было связано с директивой ng-repeat, а другое с применением фильтров.
Эта статья рассказывает о результатах наших опытов с различными подходами по решению, или смягчению, возникшей проблемы с производительностью. Это даст вам идеи и советы, куда вы можете приложить свои силы, а какие подходы все-таки не стоит использовать.Читать полностью »
Рубрика «performance» - 16
Оптимизация производительности длинных списков в AngularJS
2013-11-03 в 10:19, admin, рубрики: AngularJS, javascript, optimization, performanceРеактивный манифест
2013-09-28 в 10:44, admin, рубрики: actors, akka, asynchronous, callbacks, closure, clusters, distributed computing, elasticity, erlangvm, event loops, event-driven programming, failover, fault handling, fault tolerant, functional programming, futures, http, hyperthreading, immutability, interactive, jvm, lambda, latency, load balancing, location transparency, louse coupling, multicore, multithreading, network, no side effects, observable, Observer, parallel computing, performance, play framework, promises, pure functions, push-model, referential transparency, reliability, remoting, resilience, responsiveness, rxjava, scalability, self-heal, supervisors, synchronization, thread-safety, web applications, Анализ и проектирование систем, параллельное программированиеВ последние годы требования к приложениям значительно изменились. Десятки серверов, время отклика в несколько секунд, оффлайновое обслуживание, которое могло длиться часами, гигабайты данных — такими были большие приложения буквально несколько лет назад. Сегодня же приложения работают абсолютно на всём, начиная с простых мобильников и заканчивая кластерами из тысячи процессоров. Пользователи ожидают миллисекундного времени отклика и стопроцентного аптайма, в то время как данные выросли до петабайтов.
Первоначально эту нишу занимали крупные инновационные интернет-компании типа Google или Twitter, однако такие требования к приложениям начали всплывать во многих областях индустрии. Финансовые и телекоммуникационные компании первыми начали внедрять новые практики, чтобы удовлетворить новым требованиям, а теперь подтягиваются и остальные.
Новые требования требуют новых технологий. Предыдущие решения делали упор на управляемые сервера и контейнеры. Масштабирование достигалось засчёт покупки более крутых серверов и использования многопоточности. Для добавления новых серверов приходилось применять комплексные, неэффективные и дорогие проприетарные решения.
Однако прогресс не стоит на месте. Архитектура приложений эволюционировала в соответствии с изменившимися требованиями. Приложения, разработанные на основе этой архитектуры, мы называем Реактивными Приложениями. Такая архитектура позволяет программистам создавать событийно-ориентированные, масштабируемые, отказоустойчивые и отзывчивые приложения — приложения, работающие в реальном времени и обеспечивающие хорошее время реакции, основанные на масштабируемом и отказоустойчивом стеке и которые легко развернуть на многоядерных и облачных архитектурах. Эти особенности критически важны для реактивности.
Я хотел бы поделиться нашим опытом использования Go в течение двух лет в продакшне Iron.io. Мы одна из первых компаний, ставших использовать Go (golang) в высоконагруженных сервисах. Когда в Iron.io было принято решение об использовании этого языка, мы не знали, чего ожидать в долгосрочной перспективе, но до сих пор все идет отлично.
Я уже немного писал об этом в предыдущем посте о переходе на Go с Ruby. Но сейчас мне хотелось бы поговорить о конкретных вещах, за которые мы любим этот язык, о которых узнали во время его использованияЧитать полностью »
Почему dart2js быстрее JavaScript?
2013-04-05 в 10:18, admin, рубрики: dart, performance, переводы, метки: dart, performanceТеперь компилятор dart2js, транслирующий код из Dart в JavaScript, генерирует более быстрый код. Анализируя программу, компилятор может убрать избыточные проверки, в результате чего, код работает быстрее на современных движках JavaScript.
На графике снизу видно, что производительность кода, сгенерированного dart2js (фиолетовая линия), теперь немного превышает код, написанный от руки на JavaScript (золотая линия). Верхняя линия — код, написанный на Dart и запущенный на Dart VM. Чем выше линия на графике, тем выше производительность.
Высокопроизводительный JavaScript-параллакс
2013-04-03 в 15:57, admin, рубрики: javascript, parallax, performance, Блог компании Hot Dot, Веб-разработка, метки: javascript, parallax, performanceЗдравствуйте!
Я — Фёдор furikuretsu Ананьев, веб-разработчик студии Hot Dot, и сегодня я дам несколько простых советов для тех, кто хочет сделать своё JS-параллакс-приложение очень и очень быстрым.
Читать полностью »
Judy-массивы в PHP
2013-04-02 в 11:41, admin, рубрики: array, badoo, judy, memory, performance, php, баду, Блог компании Badoo, Программирование, метки: array, badoo, judy, memory, performance, PHP, баду 
В Badoo используется много сервисов на C и C++, большинство из которых работают с огромными объёмами данных. Как правило, сервисы выступают в роли «быстрого кэша» или «быстрой базы данных», т.е. совершают различные операции с массивами однотипных данных. Для быстрого доступа к данным мы давно и успешно используем Judy-массивы (англ. Judy arrays). Но однажды нам захотелось странного: обрабатывать большие массивы целых чисел на PHP, и мы сразу вспомнили про Judy.
Немного истории
Judy-массивы были изобретены Дугласом Баскинсом (англ. Douglas Baskins) в начале 2000-го года. Проект их разработки финансировался компанией HP, но примерно через два года был закрыт. За это время было выпущено четыре версии, причём разработка последней заняла больше года, и в ней разработчики смогли в два раза ускорить Judy, в два раза уменьшить потребление памяти, хоть и далось это нелёгкой ценой: объём кода вырос в 5 раз, а его сложность ― на порядок.
Читать полностью »
Тонкости оператора switch
2013-03-26 в 8:07, admin, рубрики: java, JDK, jit, performance, switch, метки: java, JDK, JIT, performance, switchДа, это целая статья по самому обычному switch в JDK 7. Бывает так, что накопленный материал кажется интересным и малоизвестным, а потом оказывается, что любая бабка у подъезда уже 50 лет знает об особенностях реализации switch. Но я попробую. Для затравки, предлагаю 3 вопроса:
- (Простой) Каков результат работы этого кода?
switch(5){ default: System.out.print(0); case 1: System.out.print(1); break; case 4: System.out.print(4); case 2: System.out.print(2); } - Следующие 2 варианта практически одинаковы. Немного отличаются литералами.
//Вариант 1 switch("BBBBBB"){ case "AaAaAa": break; case "AaAaBB": break; case "AaBBAa": break; case "AaBBBB": break; case "BBAaAa": break; case "BBAaBB": break; case "BBBBAa": break; case "BBBBBB": break; }//Вариант 2 switch("BBBBBB_8"){ case "AaAaAa_1": break; case "AaAaBB_2": break; case "AaBBAa_3": break; case "AaBBBB_4": break; case "BBAaAa_5": break; case "BBAaBB_6": break; case "BBBBAa_7": break; case "BBBBBB_8": break; }Почему первый switch выполняется в несколько раз медленнее, по крайней мере, с отключенным JIT (-Djava.compiler=NONE)? Сами проверьте в цикле! JIT таким кодом не проведешь, но если немного пошаманить, то небольшая разница будет заметна.
- Какова вычислительная сложность алгоритма нахождения совпадающего значения среди n case-ов (по крайней мере, в JDK 7)?
Новое в СУБД Caché 2013.1: добавление и генерация индексов на «живых» классах
2013-03-22 в 6:01, admin, рубрики: big data, cache, dbms cache, index, intersystems cache, performance, Блог компании InterSystems, высокая производительность, субд Caché, метки: big data, cache, dbms cache, index, InterSystems cache, performance, субд CachéПредположим, что у вас есть таблица с большим количеством записей и в неё нужно добавить один или несколько индексов со следующими условиями:
- их генерация должна быть максимально быстрой
- чтобы генерацию можно было производить порциями.
К примеру, если есть таблица на 300М записей и работы с ней можно производить только в нерабочее время, то чтобы можно было разбить весь процесс на три ночи по 100М записей - появление новых индексов и сам процесс их генерации не должны мешать текущей работе с классом/таблицей
Для этого можно было бы воспользоваться уже известным методом %BuildIndices(), но в таком случае это не будет удовлетворять нашим условиям.
Каков же выход?
Читать полностью »
Всегда ли библиотеки на С быстрее чем JS
2013-02-26 в 15:28, admin, рубрики: javascript, node.js, performance, высокая производительность, метки: javascript, node.js, performanceНе так давно была статья о выходе js-yaml 2.0.0, который был полностью написан на JS и при этом работал весьма быстро. И только недавно я узнал, насколько же все хорошо на самом деле :). А началось все с того, что знакомый пожаловался на руби, который долго парсил 7-мегабайтный yaml-файл. Это было довольно странно, потому что руби использует биндинги к libyaml. Мы написали несколько примитивных тестов для руби с питоном, и получили такие результаты, что я заподозрил ошибку.
Тогда создал тему на LOR, там нашли пару косяков и добавили примеров с других языков. Картину мира это улучшило, но не сильно. JS подозрительно быстр. Результат ниже, а в конце пара замечаний.
Читать полностью »
Как мы создавали кластер из Raspberry Pi
2013-02-22 в 0:24, admin, рубрики: challenge, performance, python, Raspberry Pi, wso2, Гаджеты. Устройства для гиков, извращения, кластер на коленке, кластеры, Программинг микроконтроллеров, сумасшедшие идеи 
Совсем скоро в Лондоне пройдет известная конференция WSO2Con 2013. И её ведущим будет Эбен Аптон (Eben Upton) — основатель и попечитель фонда Raspberry Pi Foundation.
Как все однажды началось...
Raspberry Pi будоражит умы гиков с тех самых пор, как была первый раз анонсирована. Мы были взволнованы услышать о том, что Эбен будет представлять конференцию и ещё больше удивлены, когда Sanjiva (прим. пер.: CEO WSO2, главный организатор конференции) предложил нам разместить бэкенд официального приложения WSO2Con на кластере из Raspberry Pi. Предложил что? Да, он всегда полон безумных идей. Первое совещание прошло 23 декабря 2012, за день перед уходом команды на рождественские каникулы. В то время мы даже не были уверены, возможно ли вообще запустить enterprise middleware на Raspberry Pi. Но исследование неизведанного — это обычное дело для WSO2, и достижение недостижимого — то, что мы делаем здесь на регулярной основе. Таким образом, группа отважных гиков бросила вызов созданию такой системы. Проект официально сдвинулся с мёртвой точки 2 января этого года.
Читать полностью »