Grande lentidão ao executar Lua como lib vinculada estaticamente versus intérprete autônomo

Estou desenvolvendo alguns algoritmos em Lua, que são executados principalmente em Lua (poucas chamadas para C ++) e estou percebendo uma grande lentidão quando os estou executando no meu aplicativo, em vez do interpretador Lua padrão. O script retorna em aproximadamente 11 segundos com o intérprete e em mais de 5 minutos no meu programa.

Eu não acho que seja um problema chamar a função C ++, substituir essa função por uma função vazia no script não tem efeito perceptível por um tempo.

Lua e o programa são compilados com o Visual Studio 2010 (criei uma nova solução para Lua, com projetos para o intérprete e a biblioteca estática)

Eu executei um criador de perfil no código (o Very Sleepy Profiler, não pode fazer com que um criador de Lua funcione, mas ainda não tentei muito) e descobri que no meu aplicativo cerca de 50% do tempo é gasto em malloc .. e Com 40% de graça, ambos chamados pelo coletor de lixo Lua (tentei desabilitar isso para verificar, mas isso trava com o uso de muita memória (compreensivelmente)), o intérprete Lua espia cerca de 4 MB de uso de RAM).

Eu sou novo em Lua, então é muito possível que eu tenha feito algo errado em algum lugar, alguém tem algumas dicas para tentar?

c++ lua

— Elva
fonte

malloc! A raíz de todo o mal! Encontramos um problema semelhante ao investigar Lua pela primeira vez e simplesmente abandonamos o esforço, por isso estou curioso para ver se há uma solução.

— Crashworks 15/10/10

Não havia uma sugestão para alterar o manipulador de memória padrão para lua para um que use realloc ... se bem me lembro, isso foi dito que era muito mais rápido em alguns casos. Mas isso foi ~ 3 anos atrás. Como você liga Lua? Se você usar o Luabind, exceto uma sobrecarga de chamada de função bastante significativa em comparação aos métodos de ligação direta ou provavelmente comparada ao toLua também.

— LearnCocos2D

Você já tentou as recomendações para otimizar o GC da lua? lua-users.org/wiki/OptimisingGarbageCollection

— David Young

@DavidYoung Eu tentei otimizando-o um pouco, tenho que cerca de 15% mais rápido, em ambos, por isso nada que realmente explicar a grande diferença de velocidade

— Elva

@GamingHorror olhando para as pilhas de chamadas, parece que o malloc está sendo chamado de realloc (luaV_execute-> luaM_realloc _-> l_alloc-> realloc-> malloc), eu também uso a API Lua C diretamente, com um pouco de dados leves do usuário para a classe que precisa ser chamada.

— Elva #

Como você diz, Lua faz alocações de memória como loucas por padrão. Você deve escrever um alocador personalizado que tenha melhor conhecimento dos padrões de alocação normalmente usados pelos programas Lua ou conectar algo como tcmalloc para obter melhor desempenho da alocação.

Eu tentei isso, economiza um pouco de tempo (alguns segundos, ainda longe do intérprete independente), talvez o problema (ou um deles) seja que o tempo de alocação não seja constante e depende da quantidade de memória disponível foi reservado antes? Isso seria solucionável usando um pool de memória apenas para Lua, eu darei uma chance (alguém tem algumas dicas para implementar isso?).

— Elva

O que economiza alguns segundos, tcmalloc? O motivo pelo qual malloc geralmente é lento não é porque o tempo de alocação não é constante (embora muitas vezes não seja) - é porque a alocação tem uma localidade de cache horrível, muita sobrecarga de bloqueio, toneladas de verificação de consistência nas compilações de depuração etc. Basicamente, você deve nunca chame malloc real (e especialmente não é de graça!) durante a execução do script - sempre use um pool de memória existente o máximo possível.