История изменений

Ты можешь сократить вычисления только если пользователь открывает таблицу реже, чем 100 секунд. Вообще в этом есть некий смысл.

Да, я об этом написал выше, наверное стоило лучше подчеркнуть. Это лишь сократит количество вызовов метода обновления карты, но не ускорит сам метод обновления карты.

Изначальная идея сократить нагрузку, а не увеличить ее.

Она не увеличивается. Синхронизация в этой модели не нужна.

Я считаю нужно искать трюки а не микро-оптимизировать саму функцию. Еще можно расширить мою модель, и рисовать хп и прогресс растения только на клиенте учитывая время и там же обновлять для вывода (обновлять только для отрисовки, никакого сохранения на сервере), а на сервере обновлять его только если игрок хочет срубить дерево, то есть при изменении, для проверки реально ли выросло растение. Тут придется иметь один и тот же код на клиенте и сервере, если есть возможность то можно просто вынести в отдельный файл.

Но если интересует только микро-оптимизация, то я заметил что соединение строк всегда быстрее чем соединение через таблицы, и в принципе таблицы не особо быстрые, это касается твоего base и обновления карты. Еще ты можешь ужимать сущность и ее здоровье в два символа, потому что ASCII это 94 знака, если объединить то как то так:

function encode94(n)
    local s = ''
    repeat
        s = string.char(32 + n % 94) .. s
        n = math.floor(n / 94)
    until n == 0.0
    return s
end

function decode94(encoded)
    local n = 0
    for i = 1, #encoded do
        n = n * 94 + (string.byte(encoded, i, i) - 32) 
    end
    return n
end

function encode94_ent(e, n)
    return encode94(e * 1000 + n)
end

function decode94_ent(s)
    local n = decode94(s)
    return math.floor(n / 1000), n % 1000
end

local tree_ent_id = 3
print(decode94_ent(encode94_ent(tree_ent_id, 999)))
print(#encode94_ent(tree_ent_id, 999))

Этот код немного быстрее твоего по моим замерам (decode_ent не измерял), и сокращает размер сущности с 3 до 2, при условии что 999 это максимальное здоровье, 8 типов сущности на одном экране, самих id типов сущностей может быть больше, просто нужно переключать палитры. Можно и альтернативное сжатие если этого мало, память точно уменьшить можно.

Ты можешь сократить вычисления только если пользователь открывает таблицу реже, чем 100 секунд. Вообще в этом есть некий смысл.

Да, я об этом написал выше, наверное стоило лучше подчеркнуть. Это лишь сократит количество вызовов метода обновления карты, но не ускорит сам метод обновления карты.

Изначальная идея сократить нагрузку, а не увеличить ее.

Она не увеличивается. Синхронизация в этой модели не нужна.

Я считаю нужно искать трюки а не микро-оптимизировать саму функцию. Еще можно расширить мою модель, и рисовать хп и прогресс растения только на клиенте учитывая время и там же обновлять для вывода (обновлять только для отрисовки, никакого сохранения на сервере), а на сервере обновлять его только если игрок хочет срубить дерево, то есть при изменении, для проверки реально ли выросло растение. Тут придется иметь один и тот же код на клиенте и сервере, если есть возможность то можно просто вынести в отдельный файл.

Но если интересует только микро-оптимизация, то я заметил что соединение строк всегда быстрее чем соединение через таблицы, и в принципе таблицы не особо быстрые, это касается твоего base и обновления карты. Еще ты можешь ужимать сущность и ее здоровье в два символа, потому что ASCII это 94 знака, если объединить то как то так:

function encode94(n)
    local s = ''
    repeat
        s = string.char(32 + n % 94) .. s
        n = math.floor(n / 94)
    until n == 0.0
    return s
end

function decode94(encoded)
    local n = 0
    for i = 1, #encoded do
        n = n * 94 + (string.byte(encoded, i, i) - 32) 
    end
    return n
end

function encode94_ent(e, n)
    return encode94(e * 1000 + n)
end

function decode94_ent(s)
    local n = decode94(s)
    return math.floor(n / 1000), n % 1000
end

local tree_ent_id = 3
print(decode94_ent(encode94_ent(tree_ent_id, 999)))
print(#encode94_ent(tree_ent_id, 999))

Этот код немного быстрее твоего по моим замерам (decode_ent не измерял), и сокращает размер сущности с 3 до 2, при условии что 999 это максимальное здоровье, 8 типов сущности на одном экране. Можно и альтернативное сжатие если этого мало, память точно уменьшить можно.

Ты можешь сократить вычисления только если пользователь открывает таблицу реже, чем 100 секунд. Вообще в этом есть некий смысл.

Да, я об этом написал выше, наверное стоило лучше подчеркнуть. Это лишь сократит количество вызовов метода обновления карты, но не ускорит сам метод обновления карты.

Изначальная идея сократить нагрузку, а не увеличить ее.

Она не увеличивается. Синхронизация в этой модели не нужна.

Я считаю нужно искать трюки а не микро-оптимизировать саму функцию. Еще можно расширить мою модель, и рисовать хп и прогресс растения только на клиенте учитывая время и там же обновлять для вывода (обновлять только для отрисовки, никакого сохранения на сервере), а на сервере обновлять его только если игрок хочет срубить дерево, то есть при изменении, для проверки реально ли выросло растение. Тут придется иметь один и тот же код на клиенте и сервере, если есть возможность то можно просто вынести в отдельный файл.

Но если интересует только микро-оптимизация, то я заметил что соединение строк всегда быстрее чем соединение через таблицы, и в принципе таблицы не особо быстрые, это касается твоего base и обновления карты. Еще ты можешь ужимать сущность и ее здоровье в два символа, потому что ASCII это 94 знака, если объединить то как то так:

function encode94(n)
    local s = ''
    repeat
        s = string.char(32 + n % 94) .. s
        n = math.floor(n / 94)
    until n == 0.0
    return s
end

function decode94(encoded)
    local n = 0
    for i = 1, #encoded do
        n = n * 94 + (string.byte(encoded, i, i) - 32) 
    end
    return n
end

function encode94_ent(e, n)
    return encode94(e * 1000 + n)
end

function decode94_ent(s)
    local n = decode94(s)
    return math.floor(n / 1000), n % 1000
end

local tree_ent_id = 3
print(decode94_ent(encode94_ent(tree_ent_id, 999)))
print(#encode94_ent(tree_ent_id, 999))

Этот код немного быстрее твоего по моим замерам (decode_ent не измерял), и сокращает размер сущности с 3 до 2, при условии что 999 это максимальное здоровье, 7 сущности на одном экране. Можно и альтернативное сжатие если этого мало, память точно уменьшить можно.

Ты можешь сократить вычисления только если пользователь открывает таблицу реже, чем 100 секунд. Вообще в этом есть некий смысл.

Да, я об этом написал выше, наверное стоило лучше подчеркнуть. Это лишь сократит количество вызовов метода обновления карты, но не ускорит сам метод обновления карты.

Изначальная идея сократить нагрузку, а не увеличить ее.

Она не увеличивается. Синхронизация в этой модели не нужна.

Я считаю нужно искать трюки а не микро-оптимизировать саму функцию. Еще можно расширить мою модель, и рисовать хп и прогресс растения только на клиенте учитывая время и там же обновлять для вывода (обновлять только для отрисовки, никакого сохранения на сервере), а на сервере обновлять его только если игрок хочет срубить дерево, то есть при изменении, для проверки реально ли выросло растение. Тут придется иметь один и тот же код на клиенте и сервере, если есть возможность то можно просто вынести в отдельный файл.

Но если интересует только микро-оптимизация, то я заметил что соединение строк всегда быстрее чем соединение через таблицы, и в принципе таблицы не особо быстрые, это касается твоего base и обновления карты. Еще ты можешь ужимать сущность и ее здоровье в два символа, потому что ASCII это 94 знака, если объединить то как то так:

function encode94(n)
    local s = ''
    repeat
        s = string.char(32 + n % 94) .. s
        n = math.floor(n / 94)
    until n == 0.0
    return s
end

function decode94(encoded)
    local n = 0
    for i = 1, #encoded do
        n = n * 94 + (string.byte(encoded, i, i) - 32) 
    end
    return n
end

function encode94_ent(e, n)
    return encode94(e * 1000 + n)
end

function decode94_ent(s)
    local n = decode94(s)
    return math.floor(n / 1000), n % 1000
end

local tree_ent_id = 3
print(decode94_ent(encode94_ent(tree_ent_id, 999)))
print(#encode94_ent(tree_ent_id, 999))

Этот код немного быстрее твоего по моим замерам (decode_ent не измерял), и сокращает размер сущности с 3 до 2, при условии что 999 это максимальное здоровье, 7 сущности. Можно и альтернативное сжатие если этого мало, память точно уменьшить можно.

Ты можешь сократить вычисления только если пользователь открывает таблицу реже, чем 100 секунд. Вообще в этом есть некий смысл.

Да, я об этом написал выше, наверное стоило лучше подчеркнуть. Это лишь сократит количество вызовов метода обновления карты, но не ускорит сам метод обновления карты.

Изначальная идея сократить нагрузку, а не увеличить ее.

Она не увеличивается. Синхронизация в этой модели не нужна.

Я считаю нужно искать трюки а не микро-оптимизировать саму функцию. Еще можно расширить мою модель, и рисовать хп и прогресс растения только на клиенте учитывая время и там же обновлять для вывода (обновлять только для отрисовки, никакого сохранения на сервере), а на сервере обновлять его только если игрок хочет срубить дерево, то есть при изменении, для проверки реально ли выросло растение. Тут придется иметь один и тот же код на клиенте и сервере, если есть возможность то можно просто вынести в отдельный файл.

Но если интересует только микро-оптимизация, то я заметил что соединение строк всегда быстрее чем соединение через таблицы, и в принципе таблицы не особо быстрые, это касается твоего base и обновления карты. Еще ты можешь ужимать сущность и ее здоровье в два символа, потому что ASCII это 94 знака, если объединить то как то так:

function encode94(n)
    local s = ''
    repeat
        s = string.char(32 + n % 94) .. s
        n = math.floor(n / 94)
    until n == 0.0
    return s
end

function decode94(encoded)
    local n = 0
    for i = 1, #encoded do
        n = n * 94 + (string.byte(encoded, i, i) - 32) 
    end
    return n
end

function encode94_ent(e, n)
    return encode94(e * 1000 + n)
end

function decode94_ent(s)
    local n = decode94(s)
    return math.floor(n / 1000), n % 1000
end

local tree_ent_id = 3
print(decode94_ent(encode94_ent(tree_ent_id, 999)))
print(#encode94_ent(tree_ent_id, 999))

Этот код немного быстрее твоего по моим замерам (decode_ent не измерял), и сокращает размер сущности с 3 до 2, при условии что 999 это максимальное здоровье.

Ты можешь сократить вычисления только если пользователь открывает таблицу реже, чем 100 секунд. Вообще в этом есть некий смысл.

Да, я об этом написал выше, наверное стоило лучше подчеркнуть. Это лишь сократит количество вызовов метода обновления карты, но не ускорит сам метод обновления карты.

Изначальная идея сократить нагрузку, а не увеличить ее.

Она не увеличивается. Синхронизация в этой модели не нужна.

Я считаю нужно искать трюки а не микро-оптимизировать саму функцию. Еще можно расширить мою модель, и рисовать хп и прогресс растения только на клиенте учитывая время и там же обновлять для вывода (обновлять только для отрисовки, никакого сохранения на сервере), а на сервере обновлять его только если игрок хочет срубить дерево, то есть при изменении, для проверки реально ли выросло растение. Тут придется иметь один и тот же код на клиенте и сервере, если есть возможность то можно просто вынести в отдельный файл.

Но если интересует только микро-оптимизация, то я заметил что соединение строк всегда быстрее чем соединение через таблицы, и в принципе таблицы не особо быстрые, это касается твоего base и обновления карты. Еще ты можешь ужимать сущность и ее здоровье в два символа, потому что ASCII это 94 знака, если объединить то как то так:

function encode94(n)
    local s = ''
    repeat
        s = string.char(32 + n % 94) .. s
        n = math.floor(n / 94)
    until n == 0.0
    return s
end

function decode94(encoded)
    local n = 0
    for i = 1, #encoded do
        n = n * 94 + (string.byte(encoded, i, i) - 32) 
    end
    return n
end

function encode94_ent(e, n)
    return encode94(e * 1000 + n)
end

function decode94_ent(s)
    local n = decode94(s)
    return math.floor(n / 1000), n % 1000
end

local tree_ent_id = 3
print(decode94_ent(encode94_ent(tree_ent_id, 999)))
print(#encode94_ent(tree_ent_id, 999))

Этот код немного быстрее твоего по моим замерам (decode_ent не измерял), и сокращает размер сущности с 3 до 2.

Ты можешь сократить вычисления только если пользователь открывает таблицу реже, чем 100 секунд. Вообще в этом есть некий смысл.

Да, я об этом написал выше, наверное стоило лучше подчеркнуть. Это лишь сократит количество вызовов метода обновления карты, но не ускорит сам метод обновления карты.

Изначальная идея сократить нагрузку, а не увеличить ее.

Она не увеличивается. Синхронизация в этой модели не нужна.

Я считаю нужно искать трюки а не микро-оптимизировать саму функцию. Еще можно расширить мою модель, и рисовать хп и прогресс растения только на клиенте учитывая время и там же обновлять для вывода (обновлять только для отрисовки, никакого сохранения на сервере), а на сервере обновлять его только если игрок хочет срубить дерево, то есть при изменении, для проверки реально ли выросло растение. Тут придется иметь один и тот же код на клиенте и сервере, если есть возможность то можно просто вынести в отдельный файл.

Но если интересует только микро-оптимизация, то я заметил что соединение строк всегда быстрее чем соединение через таблицы, и в принципе таблицы не особо быстрые, это касается твоего base и обновления карты. Еще ты можешь ужимать сущность и ее здоровье в два символа, потому что ASCII это 94 знака, если объединить то как то так:

function encode94(n)
    local s = ''
    repeat
        s = string.char(32 + n % 94) .. s
        n = math.floor(n / 94)
    until n == 0.0
    return s
end

function decode94(encoded)
    local n = 0
    for i = 1, #encoded do
        n = n * 94 + (string.byte(encoded, i, i) - 32) 
    end
    return n
end

function encode94_ent(e, n)
    return encode94(e * 1000 + n)
end

function decode94_ent(s)
    local n = decode94(s)
    return math.floor(n / 1000), n % 1000
end

local tree_ent_id = 3
print(decode94_ent(encode94_ent(tree_ent_id, 999)))
print(#encode94_ent(tree_ent_id, 999))

Этот код немного быстрее твоего по моим замерам, и сокращает размер сущности с 3 до 2.

Ты можешь сократить вычисления только если пользователь открывает таблицу реже, чем 100 секунд. Вообще в этом есть некий смысл.

Да, я об этом написал выше, наверное стоило лучше подчеркнуть. Это лишь сократит количество вызовов метода обновления карты, но не ускорит сам метод обновления карты.

Изначальная идея сократить нагрузку, а не увеличить ее.

Она не увеличивается. Синхронизация в этой модели не нужна.

Я считаю нужно искать трюки а не микро-оптимизировать саму функцию. Еще можно расширить мою модель, и рисовать хп и прогресс растения только на клиенте учитывая время и там же обновлять для вывода (обновлять только для отрисовки, никакого сохранения на сервере), а на сервере обновлять его только если игрок хочет срубить дерево, то есть при изменении, для проверки реально ли выросло растение. Тут придется иметь один и тот же код на клиенте и сервере, если есть возможность то можно просто вынести в отдельный файл.

Но если интересует только микро-оптимизация, то я заметил что соединение строк всегда быстрее чем соединение через таблицы, и в принципе таблицы не особо быстрые, это касается твоего base и обновления карты. Еще ты можешь ужимать сущность и ее здоровье в два символа, потому что ASCII это 94 знака, если объединить то как то так:

function encode94(n)
    local s = ''
    repeat
        s = string.char(32 + n % 94) .. s
        n = math.floor(n / 94)
    until n == 0.0
    return s
end

function decode94(encoded)
    local n = 0
    for i = 1, #encoded do
        n = n * 94 + (string.byte(encoded, i, i) - 32) 
    end
    return n
end

function encode94_ent(e, n)
    return encode94(e * 1000 + n)
end

function decode94_ent(s)
    local n = decode94(s)
    return math.floor(n / 1000), n % 1000
end

local tree_ent_id = 3
print(decode94_ent(encode94_ent(tree_ent_id, 999)))
print(#encode94_ent(tree_ent_id, 999))

Ты можешь сократить вычисления только если пользователь открывает таблицу реже, чем 100 секунд. Вообще в этом есть некий смысл.

Да, я об этом написал выше, наверное стоило лучше подчеркнуть. Это лишь сократит количество вызовов метода обновления карты, но не ускорит сам метод обновления карты.

Изначальная идея сократить нагрузку, а не увеличить ее.

Она не увеличивается. Синхронизация в этой модели не нужна.

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

Но если интересует только микро-оптимизация, то я заметил что соединение строк всегда быстрее чем соединение через таблицы, и в принципе таблицы не особо быстрые, это касается твоего base и обновления карты. Еще ты можешь ужимать сущность и ее здоровье в два символа, потому что ASCII это 94 знака, если объединить то как то так:

function encode94(n)
    local s = ''
    repeat
        s = string.char(32 + n % 94) .. s
        n = math.floor(n / 94)
    until n == 0.0
    return s
end

function decode94(encoded)
    local n = 0
    for i = 1, #encoded do
        n = n * 94 + (string.byte(encoded, i, i) - 32) 
    end
    return n
end

function encode94_ent(e, n)
    return encode94(e * 1000 + n)
end

function decode94_ent(s)
    local n = decode94(s)
    return math.floor(n / 1000), n % 1000
end

local tree_ent_id = 3
print(decode94_ent(encode94_ent(tree_ent_id, 999)))
print(#encode94_ent(tree_ent_id, 999))