Ссылка: Почему веб-приложения на мобильных платформах работают медленно

 
Delphi XE5 дает возможность создавать нативные приложения и для десктопа и мобильных платформ (пока что Android и iOs). Единый код, UI, все дела.
Но зачем мне для этого покупать Delphi, воскликнет искушенный читатель? Я возьму какой-нибудь бесплатный мобильный Javascript фреймворк (Cordova, PhoneGap и другие) и сделаю то же самое. Не спеши, читатель, отвечу ему я. Ведь Javascript может оказаться слиииииишком медленным.
И вот одна статья на эту тему. Только сегодня! Только на нашей арене! Javascript против нативного кода! Сравнение производительности и предсказании будущего! Статья опубликована на Хабре 8 августа 2013. Почему веб-приложения на мобильных платформах работают медленно
 
Статья по ссылке реально большая. И я позволю себе скопировать сюда выводы. …

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]

Читать на сайте автора.

Delphi XE5 с поддержкой Андроида. Первые впечатления.

Не то, чтобы я очень ждал выхода Delphi XE5. Поначалу. На самом деле я даже не следил за новостями. Но за пару недель до релиза

Читать на сайте автора.

Delphi XE5 с поддержкой Андроида. Первые впечатления.

Не то, чтобы я очень ждал выхода Delphi XE5. Поначалу. На самом деле я даже не следил за новостями. Но за пару недель до релиза (как это выяснилось позднее) ситуация поменялась. Только-только стали появляться первые обзоры от бета тестеров XE5. А я решил проверить будет ли мой Lazy Delphi Builder работать с компиляторами от XE5.
Зарегистрировался на участие в бета тесте, стал следить за новостями и как-то потихоньку втянулся в активное ожидание, с ежедневной проверкой DelphiFeeds на тему новостей. Я как-то даже не верил, что у Embarcadero получится. Уж очень амбициозная цель была поставлена. Но у них получилось. Молодцы!
Доступа к бете я тогда так и не дождался – через неделю вышла полная версия. Попытка первая.
Очень интересно, заработает ли у меня. Будет ли всё действительно…

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]

Читать на сайте автора.

Lazy Delphi Builder 1.9.7.251. 15-сен-2013 для XE5 и XE6

Для тех, кто не в курсе: Lazy Delphi Builder даёт возможность пересобрать всё что надо используя только .pas файлы. И поддерживать порядок, складывая все dcu-шки

Читать на сайте автора.

Lazy Delphi Builder 1.9.7.251. 15-сен-2013 для XE5 и XE6

Для тех, кто не в курсе: Lazy Delphi Builder даёт возможность пересобрать всё что надо используя только .pas файлы. И поддерживать порядок, складывая все dcu-шки в одно определённое место. Лицензия — халява.
Сценарии использования: Пересобрать все свои компоненты/библиотеки из исходников с нуля (актуально в случае апгрейда, чистки) Сборка нового релиза (всё собирается с нуля из pas-файлов) Установка новых больших библиотек чтобы поиграться (или пересборка старых с новыми директивами) История изменений Новое: теперь можно выбирать платформу для компиляции. Пока поддерживаются Win32, Win64 и OSX. Это сделано через замену вызова dcc32 на вызов dcc64 или dccOSX. Для использования других платформ, можно указывать нужный dcc вручную (см. пункт 9 в release notes к версии…

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]

Читать на сайте автора.

InterBase на мобилах

InterBase явно опережает Firebird в захвате рынка мобильных платформ. Вместе с Delphi XE4 разработчики получили возможность использовать InterBase (в варианте IBLite) на iOs, а для Android уже есть IBLite в редистрибутивах бета-версии Delphi XE5 (которая выйдет в начале сентября).

Вот пример приложения, работающего с IBLite на iOs и Android:
http://blogs.embarcadero.com/sarinadupont/2013/08/26/cooking-with-interbase-on-android-and-ios/

Я пока еще IBLite для Android не прикрутил, но сделаю это в ближайшие пару дней.

Здесь можно посмотреть технические спецификации IBLite и IBToGo. Напомню, что обе эти варианта InterBase являются встраиваемыми (embedded), т.е. являются подключаемой к приложению библиотекой, и одновременно выполняют как функции локального сервера, так и могут работать с удаленным сервером InterBase в качестве клиентской части.

p.s. у Firebird для мобильных устройств пока есть только клиентская часть в виде драйвера JayBird, и то в варианте, подкрученном одним энтузиастом.

Читать на сайте автора.

Сортировка списка по аналогу "Проводника Windows"

Когда проект практически завершен и вся бизнес логика находится в тестировании иногда возникает желание дополнить его «рюшечками и фишечками» и прочими «украшательствами», ну например перерисовать

http://alexander-bagel.blogspot.com/2013/06/windows.html

прошлой статье

В прошлой статье я рассмотрел пять вариантов перехвата функций включая их вариации.

Правда в ней я оставил не рассмотренными две неприятных ситуации:
1. Вызов перехваченной функции в тот момент,

http://alexander-bagel.blogspot.com/2013/05/intercept2.html

Внезапный direct I/O

На этот пост спровоцировало разбирательство на sql.ru. Там много страниц, можно не читать, здесь я обобщу полученный опыт.

Итак, СУБД Firebird и InterBase обычно используют файловый кэш при работе с БД. Вернее сказать, не «используют кэш», а при открытии файла БД указывают опции, которые включают или выключают этот кэш в определенных случаях.
Одновременно, они используют свой собственный кэш страниц БД.

Самый первый и известный случай изменения режима , это режим Forced Writes, т.е. в терминах CreateFile (Windows) включение (ON) или выключение (OFF) флага FILE_FLAG_WRITE_THROUGH. При ON операционная система осуществляет запись сразу на диск (или в контроллер raid, и т.д.). При OFF операционная система кэширует изменяемые страницы в RAM (подробнее о режимах кэша Windows).
Однако, у Firebird и InterBase существует понятие careful writes, когда изменяемые страницы записываются на диск в таком порядке, чтобы в случае внезапного сбоя (например, reset) база данных осталась максимально целой. Поскольку при OFF (включенном write cache ОС) порядок записи определяется операционной системой, а не СУБД, в случае reset БД может оказаться, скажем, в «физически нецелостном» состоянии.

Например, если добавляется новая запись, а места на страницах БД для этого нет, то создается новая страница, запись размещается на ней, затем ссылка на страницу добавляется в Pointer pages таблицы, после чего в соответствующую inventory pages для новой страницы заносится флаг «занято».
Если все это попадает в кэш ОС, то страница inventory pages может попасть на диск раньше новой страницы с записью, в результате чего при reset окажется, что страница как бы занята, и таблица ссылается на нее, а на деле в этой странице мусор (еще ничего не записано).

Что интересно, до определенного момента в Firebird на Linux режим Forced Writes = ON не поддерживался, т.е. всегда было OFF (исправлено в FB 2.1)

Вторым из режимов кэша, или режимов открытия файлов, является флаг FILE_FLAG_NO_BUFFERING (Windows), который выключает кэш ОС для этого файла вообще, т.е. в том числе и на чтение.
Мы давно экспериментировали с этим флагом в Yaffil, и выяснили, что на обычных дисках производительность резко просаживается (у IB и FB, да и у Yaffil, собственный кэш не умеет делать prefetch, в отличие от ОС), а также, что худший вариант — когда размер страницы не совпадает с размером кластера файловой системы.
В общем, по результатам теста этот флаг было решено оставить в покое.

Со временем кэш дисков, контроллеров и вообще систем хранения сильно вырос, и стал достаточно умным. Так что на некоторых устройствах есть смысл во включении Direct I/O.
Для InterBase возможность отключить кэш ОС была введена в версии XE.
В Firebird такая возможность появилась в 2.5. Для всех баз на сервере direct I/O можно включить путем установки опции FileSystemCacheThreshold=0 в firebird.conf.
Что интересно, режим direct I/O включается не только этим нулем, а и в том случае, если указанный размер кэша БД (DefaultDBCachePages в firebird.conf или page buffers в конкретной БД) больше, чем FileSystemCacheThreshold.
То есть, поскольку FileSystemCacheThreshold по умолчанию 65536, то режим direct I/O включится, если размер кэша в конфиге или БД указан больше этого значения.

Попасть на эти грабли могут разве что пользователи Firebird с архитектурой SuperServer, потому что у Classic и SuperClassic раздельный кэш БД, и выставлять значения кэша больше 65к страниц никому и в голову не придет — сервер тут же начнет отжирать память. Например, для страницы 8к 65к страниц кэша станут 512 мегабайтами RAM, потребляемыми на каждого пользователя.

С другой стороны, у SuperServer кэш БД общий для всех пользователей, и поэтому вполне разумно указать его побольше, особенно если размер БД как минимум 1 гигабайт.
Но как только вы включите такой кэш, «внезапно» для БД отрубится файловый кэш операционной системы (если не изменить параметры по умолчанию в firebird.conf).

Хорошо это или плохо — нужно проверять в конкретном случае. Ваша дисковая подсистема может оказаться настолько крутой, что отключение файлового кэша ОС для БД улучшит производительность, или, по крайней мере, освободит память ОС для других целей.
Но если нет — при задирании размера кэша БД вдруг может случиться и падение производительности.

Дополнения:

  • на Linux указанные режимы открытия файлов это O_SYNC и O_DIRECT.
  • после включения direct I/O режим Forced Writes уже не имеет значения (будет всегда ON)
  • в Firebird 2.5.2 исправлена еще одна проблема с кэшем Windows.

Читать на сайте автора.

Lazy Delphi Builder 1.8.6.240 от 28-04-2013 для Delphi XE4 и XE5

Что нового (вкратце):Поддержка Delphi XE4. И на всякий случай, сразу и Delphi XE5, — вдруг выйдет через месяц =) Профили (мини). Теперь можно сохранять профили

Читать на сайте автора.