у меня нет такого, что надо вычитывать большие файлы подряд. С этим я уж разобрался бы, читал бы большими кусками и все такое.

У меня обращение к кускам внутри больших файлов по конкретным адресам - 40 байт там, пару десятков байт там, сотня тут.

Примерно в таком формате:







Т.е. обращение к mapped файлу как к массиву.

Именно про эти два куска я писал, что менял их на TFileStream (Seek&Read) - и получил падение скорости в три раза.
Подозреваю что тут тот самый редкий случай, когда ММФ действительно нужно, и нормальной альтернативы нет.

_Vasilisk_Vizit0rу меня нет такого, что надо вычитывать большие файлы подряд.MMF именно это и делает выделяет буфер под весь файл (если Вы мапите сразу все), считывает файл в этот буфер и отдает его Вам

почитал мсдн, подумал.

Попробую сделать заново кешер, который там когда-то был, но несколько лет тому был выпилен почему-то. Надо по коммитам посмотреть, что там и как было. Может расход памяти большой, может неэфективность - надо смотреть.

Там файлов, которые мапятся- в сумме на 500 мб и больше.

добрался домой, пришел в себя и занялся делом.

Сделал конвертирование из 15битного формата в полноценный FMX RGBA 32б. Андроид по традиции преподнес сюрпризов с отрисовкой.
Вот один из них:


Другой момент - это когда присваиваешь одному битмапу другой, потом на первом рисуешь Rect - а он в тех местах, где пиксели непрозрачные - не отрисовывается. Выкатил на fire-monkey.ru вопрос, может опытные люди подскажут.
Еще всякое-разное с андроидом было, с размерами TImage, выводом изображения на него и прочее.

По коду добавил кучу дефайнов, потому что неожиданно повсплывало в куче мест \ в конце\середине пути, да и вообще много где были прописаны абсолютные пути. Все это переносится на общие переменные.

posix-mmf работает, но пока проверял только на единичных обращениях к файлу, на днях начну полноценный тест сложных систем типа поиска пути, там как раз это все будет - и нагрузка на процессор, и обращение к файлам.

забыл упомянуть еще момент.
Tbitmap -
задаешь размеры, затем
Result.Map(TMapAccess.Write,BitmapData);
затем в цикле
P := BitmapData.GetScanline(Y);
и заполняешь только те пиксели, которые используются.
И получаешь сюрприз, что в незаполненных пикселях мусор. И пофиг, что сразу после задавания размера ты делал
Result.Canvas.Clear(TAlphaColorRec.Null);

Зло где-то в районе Result.Map, я не копал глубоко, да и конкретное место неинтересно.

Приходится в каждой итерации делать

P := BitmapData.GetScanline(Y);
FillChar(PCardinalArray(P)[X], Width * SizeOf(TAlphaColor), 0);

SaperskyVizit0rИ получаешь сюрприз, что в незаполненных пикселях мусор.
Похоже, это такая оптимизация, FM в режиме "только запись" не гоняет картинку из видеопамяти, считая, что она всё равно будет полностью перезаписана.
Можно использовать TMapAccess.ReadWrite, хотя очистить картинку FillChar-ом наверняка будет быстрее.

это логично, и это первое о чем я подумал.
Только вот....




:)

авторТам по-старинке FillRect не работает?
там по-старинке почти ничего не работает, все изменено. Но более-менее логично, примеры и справка + чтение FMX сурсов нормально помогают.

может кто-то в курсе - есть ли какая-то возможность под андроид получить инфу о memory corruption ДО того как андроид вышибает со стеком, в котором фигурирует :F6EAF8AC __bionic_heap_corruption_error и прочее такого плана?
Overflow checking + Range checking не помогает.
Ошибка повторяема, проблема где-то в дельфо-андроидных конвертациях PAX'а больших структур (> 4б) при вызове из скрипта внутреннего метода приложения. Знаний, чтобы понять что там не так - явно не хватает. Если проблему структуры размером 3б я решил по аналогии с проблемами структур пакса еще для винды, то в случае большой структуры так уже не катит. Там вовсю работают конструкторы-деструкторы, фиг поймешь что и где не так.

На этой неделе было время свободное, занялся андроидной версией.


1)с удивлением узнал, что в стандарном сете иконок для андроида нет сохранения. вообще. Что-то похожее еще примерно похожее на открыть есть, а для сохранения нет.
Нашел в полном наборе materials ( https://material.io/icons) иконку сохранения, попробую ее на досуге впилить в стиль.

2) Долго ругался на вызов файлдиалога. Благодаря тому, что с какой-то версии FMX не поддерживает ModalWidows, все действия после вызова файлдиалога пришлось переносить в коллбеки. Особенно классно выглядит это, когда в одной цепочке может быть несколько вызовов файлдиалога, например при открытии файла запрос на сохранение измененного с файлдиалогом для выбора куда сохранить, а потом за ним опендиалог.

3) на удивление легко и правильно завелись Notifications. Неожиданно.

4) поимел вдоволь секса с попыткой сделать редактирование в android-style, когда при редактировании строки или поля оно взлетает наверх, чтобы было видно при открытой виртклаве. Так вот, сделать это легко и просто получается только для TEdit. Для TMemo - все сложно, оно-то наверх прыгает, но при этом верхняя часть уходит за экран. Долго и нудно возился, пока не сделал в лоб - при показе VK меняю layout с tmemo стиль alTop и выставляю нужный Height.
Пробовал и примеры из дельфийского набора, и vkbdhelper.

5) довеском про tmemo - большие проблемы с лонг-тапом и тем, что из него вытекает. Меню показывается, но если нажать на кнопку в появившемся меню или попытаться изменить область выделения - отличный шанс вылететь с невнятной ошибкой в потрохах переходников явы. Пришлось отключить LongTap, но все равно при желании можно получить краш. Что-то там сильно неладно в потрохах. Надо спросить на fire-monkey.ru, может у кого есть решение.

6) андроид 8 походу еще не поддерживается - приложение деплоится, работает нормально, но при этом среда виснет на Launching Application. Т.е. отлаживать на 8 дроиде не получится.



P.S. Кстати, после покупки нового домашнего компа с i5 на борту - компиляция под андроид перестала быть чем-то смертельным, когда можно ставить на компиляцию и уходить кушать, курить и пить кофе. Ощутимо дольше, чем VCL, но уже можно жить. Тот случай, когда проц действительно имеет значение. Знал бы, что будет такой эффект - может и на i7 бы разорился.

по нынешним временам мало - всего 8 гб. Но я в игры не играю, мне больше точно не надо.

А до этого был какой-то целерон убогий и 2 гб памяти. Старый комп тогда сгорел, денег небыло, пришлось покупать все самое дешевое. Ноут быстрее работал, чет это убожество.