Лидеры

Конкретно на этом участке быстродействие кода не критично, а поле для оптимизаций в программе пока ещё не исчерпано. Но пусть будет. Это зависит от того, что именно для нас хорошо. С точки зрения быстродействия лучше вообще не создавать и не вызывать функции. И локальные переменные внутри часто вызываемых функций тоже лучше не создавать. Но читать и дорабатывать такой код будет не просто. Хороший код всегда является результатом компромисса между быстродействием, потреблением памяти и простотой обслуживания кода. Баланс определяется условиями задачи. Поэтому говорить о качестве кода в отрыве от условий задачи бессмысленно. Да, смысл есть, это полезный приём, позволяющий упростить код. А долго ли... Зависит от выбора единицы измерения, из которых наиболее адекватной в большинстве случаев является процент времени, затрачиваемый на выполнение участка кода по отношению к содержащей его функции – либо непосредственно функции, содержащей этот код, либо вызывающими её функциями вплоть до всей программы целиком. Скорее всего, нет. Это надо проверять в каждом конкретном случае. В общем же это выглядит так: Обращение к локальным переменным требует меньше времени, чем к глобальным переменным или же полям таблицы. Поэтому локальные переменные позволяют увеличить быстродействие в большинстве случаев. Но локальные переменные требуют времени на их создание и уборку мусора. И если функция, содержащая локальную переменную, вызывается слишком часто, то эти накладные расходы могут превысить затраты на обращение к глобальной переменной или полю таблицы.

Начну, с loadProperities, функции чтения конфигурации. В ней несколько раз встречаются строки вида string.byte(bytes, ...) и string.sub(bytes, ...). Я предлагаю использовать синтаксический сахар, предоставляемый Lua для более компактной записи: bytes:byte(...) и bytes:sub(...). На поведении программы это не отразится, но код станет светлее, что благоприятно скажется на его чтении. Там же встречается такая строчка: (enabled == 1 or true and false). В использованном контексте брать это выражение в скобки не обязательно, а с точки зрения замусоривания кода лишними символами – вредно. А кроме того, результатом выполнения выражения enabled == 1 уже является true или false, поэтому вся эта длинная запись приводит ещё и к бесполезному дублированию вычислений. С тем же успехом для булевой переменной var можно было бы написать длинное if var then return true else return false end вместо лаконичного return var Такой подход приводит к раздуванию кода на пустом месте. Поэтому, учитывая сказанное выше, строчку сокращаем до enabled == 1. Зато в функции saveProperities эта конструкция облегчит код: local enbd = 0 if filter.enabled then enbd = 1 end до local enbd = filter.enabled and 1 or 0 Да и к слову, зачем нужна переменная enbd, если её значение используется лишь один раз, и можно было сразу писать такой код: local enabled = string.char(filter.enabled and 1 or 0) local input_side = string.char(filter.input_side) ... Также я бы предпочёл избавиться от длинной последовательности string.char, осветлив код, заодно уменьшив количество вызовов функции char и количество переменных, заменив этот код local enabled = string.char(enbd) local input_side = string.char(filter.input_side) local output_side = string.char(filter.output_side) local input_slot = string.char(filter.input_slot) local output_slot = string.char(filter.output_slot) local name_length = string.char(#filter.name) local name = filter.name local metadata = string.char(filter.metadata) local count = string.char(filter.count) bytes = bytes .. enabled .. input_side .. output_side .. input_slot .. output_slot .. name_length .. name .. metadata .. count на более короткий и эффективный вариант: bytes = bytes .. string.char( enbd, filter.input_side, filter.output_side, filter.input_slot, filter.output_slot, #filter.name ) .. filter.name .. string.char( filter.metadata, filter.count) Такой код не только требует меньше действий, но и выглядит понятнее, на мой вкус. Есть ещё пара строк в этой функции, за которые цепляется глаз: for i = 1, #filters, 1 do local filter = filters[i] Их хочется заменить одной строкой: for i, filter in ipairs(filters) do Такой код легче читается. Быстродействие этого участка кода, скорее всего ухудшится, что вряд ли сыграет какую-либо роль конкретно в этом месте. Вот примерно так можно улучшить функции чтения и записи конфигурации. Для дальнейшего улучшения можно было бы сменить формат файла, но это улучшение будет относительным. Сейчас выбран двоичный формат хранения данных. Его преимущество в компактности хранения. Зато некомпактен код работы с файлом конфигурации. В данной программе я бы предпочёл хранить конфигурацию в виде сериализованной таблицы. Это сильно упростит код загрузки и сохранения конфигурации, позволяя не думать о деталях. Заодно файл можно будет просматривать и редактировать простыми текстовыми редакторами, что может оказаться даже более удобным, нежели редактор, встроенный в программу. Сам файл конфигурации, правда, увеличится в размерах. Но вряд ли его размер будет играть существенную роль. Предлагаю рассмотреть этот вариант, хотя и совершенно не настаиваю на нём. А если вообще отказаться от встроенного редактора, то я бы предпочёл загрузку конфигурации в виде Lua-кода. Примеры кода сейчас не предлагаю, потому как не уверен в их востребованности в этой теме.