Postagem em destaque

A incrível velocidade do Go

Imagem
Um dos motivos que gosto do Go (a linguagem de programação, não o jogo), é que ele é extremamente rápido. E não estou falando de utilizar goroutines pois aí é covardia. Estamos migrando um sistema de Coldfusion para Go e PHP e uma das rotinas insere um registro no banco de dados no início e outra no fim do processo. Pense como se fosse um log, mas um log específico para essa rotina. Dessa forma: 2023-05-18 17:45:03. 687     ... [processaImagem] Incorporando imagem 2023-05-18 17:45:03. 688     ... [processaImagem] Imagem incorporada Entre o inicio e o final do processamento levou 1ms. Até aí, tudo bem, se não fosse o fato dessa tabela ter o campo timestamp como parte da chave primária. Se reparar, o tempo é definido em milissegundos. Com o Coldfusion esse processo dura cerca de 20ms. Simplesmente migrando para Go, o tempo caiu muito, para menos de 1ms e assim, começou a dar erro de chave duplicada. A solução? Depende, sempre depende. No nosso contexto, a mais simples foi feita, pois nã

Faça o simples

Comecei a programar bem cedo, em 1985, num TK-2000. Naquela época tinha que se virar com meros 48 KB (isso mesmo, não são 48 MB) de memória RAM e talvez por isso aprendi a fazer programas enxutos.

Lembro que quando trabalhava com Clipper, tive que criar um módulo de abertura/fechamento de tabelas do BD, pois se ficasse com muitas tabelas abertas simultaneamente dava problema de falta de memória. Assim, o programa ficava monitorando as tabelas, e cada vez que uma era aberta, subia uma posição na fila. As que ficavam no final da fila, abaixo de um determinado limite, eram fechadas automaticamente.

Em sistemas maiores, sempre tem quem tente cercar todas as possibilidades: "e se, o usuário quiser, mais tarde, um relatório por filial", "e se, no futuro, for preciso aplicar uma correção na tabela XYZ", "e se, ...".

Reparem que são suposições ("e se") projetadas para um momento que não se sabe se ocorrerá ("mais tarde", "no futuro"). Mas atenção: em momento algum disse que não é preciso prever certas situações. Pelo contrário, o bom analista/programador precisa saber distinguir essas situações. Mas é preciso ficar atento à, digamos, preparação do código para novas funcionalidades. Isso pode gerar, no mínimo, tempo gasto sem necessidade.

Para saber mais: Curiosity e suas 2,5 milhões de linhas de código


Comentários

Postagens mais visitadas deste blog

Netflix não mostra ícone de streaming

Google Hacking

FTP não funciona no PHP