Fator de carga de tabela hash

Esta calculadora faz essa operação, compara o resultado com o limite que você escolher e informa se o redimensionamento é recomendável. Ela também estima a quantidade mínima de buckets que deixaria os itens atuais estritamente abaixo do limite. Use a ferramenta para revisar uma implementação, planejar capacidade, verificar o estado observado de uma tabela ou transformar uma política de redimensionamento em um teste automatizado e repetível.

Calcule o fator de carga com contagens coerentes

Informe a quantidade de itens armazenados atualmente e o número de buckets alocados. A calculadora divide a contagem de itens pela de buckets; assim, 600 itens distribuídos em 800 buckets resultam em fator de carga 0.75, ou 75%. Conte entradas lógicas, e não buckets ocupados: duas entradas que colidem e compartilham um bucket ainda contam como dois itens. Da mesma forma, use a capacidade real de buckets da tabela, não apenas aqueles que contêm algum item. Essas definições precisam permanecer coerentes porque o fator representa a média de entradas por bucket, e não a porcentagem de buckets não vazios. A contagem de itens pode ser zero, mas a de buckets deve ser um inteiro positivo, pois a divisão por zero não descreve um estado válido. Faça cálculos separados para tabelas, shards ou partições independentes. Somar as contagens pode esconder uma partição sobrecarregada atrás da capacidade ociosa de outra, mesmo que a relação geral pareça aceitável. O decimal e a porcentagem retornados representam a mesma relação em formatos adequados para código e relatórios.

Escolha e interprete o limite de redimensionamento

O limite é o fator de carga no qual sua política determina um redimensionamento. O padrão é 0.75, mas você pode fornecer qualquer valor finito e positivo compatível com o projeto. Tabelas com endereçamento aberto geralmente precisam de limite abaixo de 1, pois cada item ocupa uma posição e as sequências de sondagem aumentam à medida que os espaços livres desaparecem. Implementações com encadeamento separado podem operar acima de 1 porque vários itens podem compartilhar um bucket, embora o custo das colisões tenda a crescer junto com a relação. A calculadora não presume uma estratégia de colisão; ela aplica o limite informado. A fronteira é inclusiva: o redimensionamento é recomendado quando o fator não arredondado é igual ou superior ao limite. A comparação usa o valor completo, enquanto o fator exibido é arredondado para garantir uma saída estável. Isso impede que o arredondamento visual altere a decisão perto da fronteira. Considere o resultado uma avaliação da política declarada, e não uma prova de que um único limite seja ideal para toda carga, função hash, orçamento de memória ou meta de latência.

Transforme o resultado em uma decisão de capacidade

Quando o redimensionamento é recomendado, o resultado inclui o menor número matemático de buckets que colocaria os itens atuais estritamente abaixo do limite escolhido. O cálculo toma a parte inteira inferior da divisão da quantidade de itens pelo limite e soma um. A saída também informa quantos buckets adicionais isso representa em relação à alocação atual. Trata-se de um mínimo definido pela política, não necessariamente da capacidade exata que sua implementação deve alocar. Muitas tabelas crescem geometricamente, frequentemente dobrando a capacidade; outras exigem uma potência de dois, um número primo ou uma capacidade aceita por um alocador fixo. Arredonde o mínimo para cima até o próximo tamanho válido e considere inserções futuras para evitar que a tabela cruze o limite logo em seguida. Se o redimensionamento não for indicado, os buckets adicionais serão zero, mesmo que o mínimo calculado seja menor que a alocação existente. Em automações, use o indicador booleano como condição estável e preserve contagens, limite e fator nos registros. A API determinística custa US$ 0,002 por solicitação e usa o mesmo cálculo disponível no navegador.