Cache Infrastructure

O HotPDF oferece um cache de memória ponderado e limitado para objetos intermediários reutilizáveis e um cache persistente de páginas renderizadas usado pela renderização de documentos carregados

Cache de memória com peso

THPDFWeightedCache em HPDFCache assume a posse de valores TObject, indexa-os por AnsiString e despeja os valores usados menos recentemente até que o peso combinado caiba em MaxBytes

Get e TryGet promovem um acerto a usado mais recentemente e atualizam as estatísticas de requisições
Peek e ContainsKey inspecionam entradas sem alterar a recência nem as estatísticas de requisições
Put assume a posse, substitui uma chave existente no lugar e aceita com segurança o mesmo objeto de novo quando só o peso dele muda
Remove libera uma entrada, enquanto Extract transfere a posse ao chamador
Reduzir MaxBytes despeja entradas imediatamente, e TrimToBudget expõe explicitamente a mesma operação de convergência
Hits, Misses, HitRate, Evictions, Rejections e Replacements expõem o comportamento do cache, enquanto ResetStatistics inicia um novo intervalo de medição
A capacidade de slots cresce geometricamente e as entradas vivas permanecem encadeadas em ordem de recência com tempo constante

Chaves de conteúdo

function HPDFCacheKeyOfBytes(const Bytes: TBytes): AnsiString;
function HPDFCacheKeyOfStream(Stream: TStream): AnsiString;

As duas funções retornam a mesma chave hexadecimal SHA-256 em minúsculas para o mesmo conteúdo

HPDFCacheKeyOfStream calcula o hash sem alocar um segundo array de bytes de tamanho completo, lê streams posicionáveis a partir da posição zero e restaura a posição original deles

Cache de decodificadores de fontes carregadas

Cada instância de THotPDF retém decodificadores de fontes carregadas parseados com sucesso em um cache LRU com peso no escopo do documento

O orçamento padrão é de 32 MiB com um limite rígido de 128 entradas, e um orçamento de zero bytes desativa a retenção
Dicionários de fontes indiretas compartilhadas reutilizam um mesmo núcleo parseado entre páginas, mesmo quando as páginas usam nomes de recursos diferentes
Extração de texto, exportação SVG, substituição de texto carregado e requisições explícitas de decodificador compartilham o mesmo cache
GetLoadedFontDecoder copia em profundidade os arrays gerenciados para que chamadores não possam mutar mapeamentos ou larguras em cache
Recarga de documento, mutação do grafo, invalidação de página, JSON Patch e toda atribuição a CMapResourcePath limpam os decodificadores retidos
A aquisição de decodificador é serializada por documento para evitar parse duplicado de uma mesma fonte, mas o lock não torna segura a mutação concorrente do documento
GetLoadedFontDecoderCacheInfo expõe entradas, bytes estimados, orçamento, acertos, erros, parses, despejos e invalidações

Cache de decodificação de imagens carregadas em shards

Cada instância de THotPDF coordena a reutilização da decodificação de imagens carregadas por meio de 16 shards de metadados com locks independentes

A busca e a admissão no cache seguram apenas o shard selecionado, enquanto a decodificação cara de filtros e imagens roda fora dos locks do cache
Um singleflight exato por chave elege um único decode dono e faz chamadores duplicados esperarem o mesmo resultado concluído
O ImageCacheMaxBytes configurado, o limite de contagem de entradas e o limite por entrada permanecem globais em todos os shards
As entradas de imagens decodificadas guardam handles imutáveis com contagem de referência que sobrevivem ao despejo e permitem que renderizadores desenhem acertos aquecidos sem materializar uma cópia em TBitmap
As imagens concluídas são copiadas para instâncias de TBitmap de posse do chamador, para que ele não possa mutar os pixels retidos no cache
A recarga de documento e a invalidação do cache de imagens limpam as entradas concluídas, enquanto objetos de flight ativos mantêm o próprio tempo de vida com contagem de referência
GetImageDecodeConcurrencyInfo informa flights ativos, decodes donos ativos e de pico, esperas, conclusões e falhas

Cache de transformações ICC

HPDFICC compartilha transformações completas de origem para sRGB por meio de um cache LRU com peso de 64 MiB thread-safe, incluindo perfis de proof e de saída quando configurados

A chave SHA-256 cobre o conteúdo completo dos perfis de origem, proof e saída, o rendering intent efetivo e a configuração de compensação de ponto preto
HPDFGetICCTransformCacheInfo informa acertos, erros, despejos, rejeições, contagem de entradas, bytes atuais e bytes máximos
HPDFSetICCTransformCacheMaxBytes aplica imediatamente um novo orçamento no escopo do processo e despeja transformações usadas menos recentemente conforme necessário
HPDFClearICCTransformCache libera as transformações retidas e zera as estatísticas de requisições sem invalidar interfaces de transformação já mantidas por chamadores

Cache persistente de subconjuntos de fontes

Defina THotPDF.FontSubsetCacheFolder para habilitar resultados de subset TrueType e OpenType reutilizáveis enquanto EnableFontSubsetting estiver ativo

A chave cobre os bytes originais da fonte, o bitmap exato de glifos usados, o modo compact ou sparse e a versão do schema do cache
Tanto o caminho normal do font-store GDI quanto o finalizador de fontes Unicode registrado reutilizam o mesmo cache
Entradas compact de PDF/A preservam o mapa de GID antigo para novo e a contagem de glifos nova de que CIDToGIDMap precisa
As entradas são validadas antes do uso, entradas corrompidas são removidas e a substituição usa uma movimentação atômica no mesmo diretório
FontSubsetCacheMaxBytes aplica imediatamente e despeja os arquivos exatos de cache acessados menos recentemente sem percorrer pastas não relacionadas
GetFontSubsetCacheInfo informa acertos, erros, gravações, despejos, corrupções, rejeições, falhas de gravação, bytes e arquivos
ClearFontSubsetCache remove apenas entradas de subset de fontes e entradas temporárias abandonadas da pasta configurada

PDF.EnableFontSubsetting := True;
PDF.FontSubsetCacheFolder := 'C:\ProgramData\MyApp\HotPDF\FontSubsets';
PDF.FontSubsetCacheMaxBytes := 256 * 1024 * 1024;

Cache persistente de páginas renderizadas

Defina THotPDF.RenderCacheFolder para habilitar a camada de disco usada após o cache de páginas renderizadas em memória

Os arquivos de página são chaveados pelo conteúdo do documento, índice de página de base zero, DPI, visibilidade efetiva de optional content, intenção de cor e política de fallback
Mudanças de camada e de intenção de cor selecionam variantes de estado reutilizáveis em vez de descartar todos os bitmaps em cache
As atualizações de PNG e do índice são atômicas, e arquivos temporários abandonados são removidos durante a recuperação
As leituras de página renovam a recência no nível de página, enquanto os limites de contagem de documentos, de páginas e de bytes despejam os dados usados menos recentemente
Reduzir um limite configurado converge imediatamente, em vez de esperar uma gravação posterior
Arquivos PNG corrompidos, linhas de índice obsoletas ou duplicadas, pastas ausentes e pastas de cache não indexadas são reparados automaticamente
Chaves de documento e coordenadas inválidas são rejeitadas antes do acesso ao filesystem
Pastas de documento que são links são ignoradas durante recuperação, leituras, gravações, invalidação e eviction; os links e os arquivos de destino externos deles são preservados

Ownership

THPDFWeightedCache assume a posse dos valores passados a Put, a menos que um valor seja retornado por Extract
THPDFDiskPageCache.Lookup retorna um bitmap recém-alocado de posse do chamador
Valores de bitmap passados a THPDFDiskPageCache.Store permanecem de posse do chamador