Лидеры

Когда то была идея сделать нормальные коллекции для OC. К примеру как в джаве. Всякие ArrayList, LinkedList, HashMap, TreeSet, ... . Потом я подумал о том что б сделать эти коллекции с записям данных на диск. Но сами понимаете записывая в 1 файл быстро упрёмся в лимит по ОЗУ. Да и парсить большой файл ради 1 элемента глупо. И тут я нашел интересную штуку под названием unmanaged drive Сначала я ставился скептически к нему. Думал все равно будет долго и тд. Но позже решил провести тестирование перфоменса Я решил сначала попробовать записывать в сектора. И увидеть сколько операций можно сделать в 1 секунду. И результаты меня приятно удивили. Я смог записать в 1280 секторов (1 сектор = 512 bytes) за чуть больше 1 секунды. \ Но позже мое тестирование немного огорчило меня. Но все равно этот диск даже с этой проблемной очень быстрый. Я провел тот же эксперимент, но уже записывал в сектора не по порядку. В предыдущем тесте я записывал в первый сектор потом во второй и тд. В этом тесте я записываю в 1 потом в 32 потом 64 и потом когда дойду до 1024 возвращаюсь к 2 и тд ... В этом случае запись в файл заняло 4 секунды против 1.33. Получается диск, работает приблизительно, как и реальный диск. Где двигать каретку это дорогостоящая операция. Но даже в таком случае перфоманс меня устраивает. В следующем тесте показывается что чтение быстрее чем запись в 2 раза. Позже я реализовал какую не какую TreeMap. Очень сырую, но сделал для тестирования перфоменса в реальных условиях. Мапка была сырая с багами и тд. Также и либка что позволяет работать с unmanaged disk тож баганутая и сырая. Но я смог увидеть реальные результаты. Я записывал в пустую мапку 1000 элементов поочереди. То есть не какой-то putAll механизм. А простой put вызвал 1000 раз. На запись этих 1000 элементов ушло 43 секунд. Что очень даже неплохо. ~23 элементов в секунду. Притом что это можно ускорить раз в 100 реализовав putAll метод. Далее я попытался прочить 1000 элементов по ключах. И на это ушло 17 секунд. Также и при тестирование так как код сырой делалось много лишних движений. Без каких думаю все б работало быстрее. И также небыло механизма балансировки дерева что может сильно повлиять на результат Притом прошу заметить что это TreeMap а не HashMap. HashMap был бы в раз 10 точно быстрее. Выходит что при помощи unmanaged drive мы можем легко обойти 1 тик штрафа при открытии файла. И записывать и читать данные намного быстрее. Также мы можем хранить данные в них, а не в ОЗУ используя коллекции. Экономя очень много памяти.

@ECS Спасибо большое! Я буду использовать второй метод, раз уж И он какой-то более адекватный, или как) Скорее всего, более понятный, и наглядный. Ps. У меня сработало только с local config = serialization.unserialize(file:read("*a")) А не local config = serialization.deserialize(file:read("*a")) Но это мелочи . Ещё раз спасибо!

Ты спросил "чем данная ось планшетная" - я ответил. Зачем пытаться сравнивать два разных продукта? Повторюсь, планшетные ОС, в отличие от десктопных, не перегружены визуальным мусором, который на экранах с малым разрешением/диагональю выглядит неуместно. У них другой подход к позиционированию, другой принцип по работе с многозадачностью, single app view, все дела. Адаптированные планшетные ОС зачастую выигрывают по части UX у универсальных десктопных - surface/vivobook тому в пример. Отчасти по этой причине ирл до сих пор существует чёткое разделение между планшетами и ультрабуками, хотя железо первых уже лет 10 как позволяет запускать десктопные ОС. Хотя наверняка первичными факторами выступают коммерция и рыночные устои со времен, когда продукты на планшетных ОС стали прибыльны

В конец библиотеки надо return data. Потом стоит перезагрузить компьютер (или выполнить в интерпретаторе lua package.loaded['data'] = nil), чтобы старая библиотека была удалена из кэша.

Как минимум пагинационным концептом взаимодействия вместо оконного, когда максимум полезной площади маленького планшетного экрана отдается текущему приложению, а также сбалансированной цветовой гаммой, которую на экранах 2 тира хрен подберешь без боли

Проблема в том, что ты записываешь данные о логине/пароле в оперативную память, которая по аналогии с реальной жизнью энергозависима - т.е. при выключении/перезагрузке компьютера она очищается. Ну и да, ты прав, логичным решением проблемы будет использовать ПЗУ вместо ОЗУ А вариантов хранения данных довольно много. Например, вот самый простой, когда логин хранится в отдельном файле а-ля login.txt local io = require("io") -- Запись local login = "MyNickName" local file = io.open("/login.txt", "w") file:write(login) file:close() -- Чтение local file = io.open("/login.txt", "r") local login = file:read("*a") file:close() Или вот более комплексный, позволяющий сохранять конфиги твоих разработок в виде сериализованных (сконвертированных в строку) луа-таблиц (массивов), а затем читать их из файла. В майноське, как и в 99% софта, реализован плюс-минус он: local io = require("io") local serialization = require("serialization") -- Запись local config = { login = "MyNickName", lastAuthorization = "09.04.2022 15:00:00", interfaceColor = 0xFF0000 } local file = io.open("/config.txt", "w") file:write(serialization.serialize(config)) file:close() -- Чтение local file = io.open("/login.txt", "r") local config = serialization.deserialize(file:read("*a")) file:close() Ну и полноценные СУБД со сложностью "за гранью богоподобия". Чисто для ознакомления, это не для нас, смертных:

Хех, в публичные сборки даже опенкомпы мало кто ставит, а ты про правку конфига и подозрительные для среднего админа операции с лимитами. Однако по функционалу твой продукт выглядит вполне вкусно. Почему бы не перевести его из гипертрофированного биоса в самостоятельную ОС? И кодить станет проще, и простор для творчества шире, и костылей в виде минификации/конфигов не потребуется, и конкуренция какая-никакая имеется На текущий момент topBiosV7 би лайк: