Mapa lento
Diagnosticar e resolver lentidão: arquivos inchados, memória da JVM, efeitos gráficos e fórmulas caras.
Mapa lento🔗
Sintoma. O mapa demora a abrir, engasga ao arrastar, ou o Freeplane trava ao rolar.
O que você vai aprender
- Separar “muitos nós” de “conteúdo embutido demais” pelo tamanho do arquivo
- Identificar as causas mais comuns de lentidão
- Devolver fluidez sem perder conteúdo
Diagnóstico rápido🔗
Comece pelo tamanho do arquivo:
ls -lh mapa.mm
xmllint --xpath 'count(//node)' mapa.mm| Nós | Tamanho esperado | Se estiver muito acima |
|---|---|---|
| 500 | ~100 KB | Investigue |
| 2.000 | ~500 KB | Investigue |
| 10.000 | ~3 MB | Normal |
Um mapa de 500 nós com 40 MB tem conteúdo embutido, não nós demais.
Causa 1 — imagens embutidas🔗
A causa mais comum de arquivos inchados.
grep -c 'base64' mapa.mm
Cada ocorrência é um arquivo embutido em texto. Imagens coladas (Ctrl+V) são embutidas por padrão.
Solução: substitua por imagens referenciadas com caminho relativo. Salve os arquivos numa subpasta img/, ative caminhos relativos em Preferências → Ambiente, e reinsira por arrasto.
Reduza também a resolução: uma imagem de câmera desenhada a 200 px continua sendo carregada inteira na memória.
Causa 2 — HTML colado em notas🔗
Colar de um navegador traz estilos inline em quantidade absurda.
grep -o 'style="[^"]*"' mapa.mm | wc -l
Centenas de ocorrências indicam o problema.
Solução: no editor de notas, alterne para o modo de edição de HTML fonte e limpe, ou use Editar → Remover formatação. De hoje em diante, cole com Ctrl+Shift+V (texto puro).
Causa 3 — memória da JVM🔗
O Freeplane roda em Java com um limite de heap. Mapas grandes o estouram e o programa passa a gastar tempo em coleta de lixo.
O limite fica no script de inicialização ou no arquivo de configuração da instalação, como -Xmx:
# Linux — em /usr/share/freeplane/freeplane.sh ou similar
_JAVA_OPTIONS="-Xmx4096m"
# Windows — freeplane.l4j.ini na pasta de instalação
-Xmx4096m
Ou por variável de ambiente antes de iniciar:
_JAVA_OPTIONS="-Xmx4096m" freeplane mapa.mm
Passar de 1 GB para 4 GB resolve a maioria dos casos em máquinas modernas.
Causa 4 — efeitos gráficos🔗
Em Preferências → Aparência, desligue:
- Anti-aliasing (dos nós e das arestas)
- Sombras
- Gradientes de fundo
Cada um custa tempo de desenho a cada quadro. Em máquinas modestas ou mapas grandes, a diferença é grande.
Causa 5 — conectores demais🔗
Conectores são recalculados e redesenhados constantemente, especialmente os curvos.
grep -c 'arrowlink' mapa.mm
Mais de trinta num mapa aberto pesa. Reduza, ou trabalhe com filtro ligado — conectores cujos extremos estão ocultos não são desenhados.
Causa 6 — fórmulas caras🔗
Uma fórmula que percorre node.branch numa raiz de dez mil nós roda a cada recálculo. Várias delas multiplicam o custo.
Soluções:
- Prefira
node.childrenanode.branchquando o resultado for equivalente. - Evite fórmulas que busquem no mapa inteiro (
node.map.root.find { ... }) em muitos nós. - Para valores que mudam raramente, considere um script que grave o resultado como valor fixo, rodado sob demanda.
Causa 7 — muitos mapas abertos🔗
Cada aba mantém o mapa inteiro em memória. Vinte mapas abertos consomem vinte vezes.
Feche o que não está usando.
Solução estrutural🔗
Se nada acima resolve, o mapa é grande demais. Divida por assunto, ligando os arquivos com hiperlinks relativos — o procedimento está em Mapas grandes.
Ganhos: cada arquivo abre rápido, o histórico do Git fica compreensível, e duas pessoas podem trabalhar sem conflito.
Checklist🔗
[ ] grep -c base64 → imagens embutidas?
[ ] grep -c 'style="' → HTML colado?
[ ] grep -c arrowlink → conectores demais?
[ ] -Xmx aumentado?
[ ] Anti-aliasing e sombras desligados?
[ ] Fórmulas sobre branch em mapas grandes?
[ ] Mapas desnecessários fechados?
[ ] Mapa passou de 5.000 nós? → dividirVocê aprendeu
- Comece medindo: tamanho do arquivo contra número de nós
- Imagens embutidas em base64 são a causa mais comum de arquivo inchado
- Sombras, anti-aliasing e fórmulas em excesso custam desempenho de desenho
- Dividir um mapa que cresceu demais costuma ser melhor que otimizá-lo
Perguntas para reflexão
- Um mapa de 500 nós com 40 MB indica qual problema?
- Que comando conta os nós de um
.mmsem abrir o Freeplane? - Cite dois ajustes de aparência que custam desempenho.
- Quando dividir o mapa é preferível a otimizá-lo?