Pular para o conteúdo principal
ProdutosFerramentas de desktopTASTECADVisualização de desenhosTASTEFILESGerenciamento de arquivosTASTEFTPTransferência de arquivosTASTESSHEspaço de trabalho remotoTASTEZIPCompactação e extraçãoFerramentas para desenvolvedoresTASTECODEAmbiente de desenvolvimento integrado para RustTASTESTUDIOAmbiente integrado de desenvolvimento e testesTASTEETLIntegração de dados (ETL)ServidoresTASTEREMOTEServidor de área de trabalho remotaTASTEGEOServidor geoespacialTASTEMAILEspaço de trabalho de e-mailComeçarDownloadsDocumentaçãoComprarTodos os produtos
Marketplace
Notícias
TecnologiaNotíciasNotícias de desenvolvimento de hojeDocumentaçãoLinguagens de programaçãoRustTypeScriptJavaScriptPythonGoC#JavaCC++KotlinDartFrameworks de front-end webNext.jsReactVue.js · NuxtSvelteKitAngularFrameworks de servidorSpring BootDjangoFastAPIASP.NET CoreNestJS · ExpressFrameworks de apps e desktopTauriFlutterReact NativeElectronAlgoritmosFundamentos de algoritmosAlgoritmos essenciaisAlgoritmos avançadosAlgoritmos práticos
ComunidadeProjetosRegistros de desenvolvimentoPromptsProblemas de ferramentas de IAVitrineGuia da comunidade
ColaboreTransferência técnicaConstrução de siteConstrução de app de desktopPipeline de lançamento e pagamentoParceiro de vendasContato
ServiçosÁrea de trabalho remotaPacotes de instalação sob medida
TASTEDEV
Produtos

Ferramentas de desktop

TASTECADDesenhos complexos, abertos com levezaTASTEFILESSó os arquivos de que você precisa, o mais rápido possívelTASTEFTPO caminho mais organizado para seus arquivosTASTESSHEntre você e o servidor, uma conexão mais sólidaTASTEZIPCompacte mais rápido, extraia com mais segurança

Ferramentas para desenvolvedores

TASTECODEEdite, compile, depure e teste apps Rust em uma única janelaTASTESTUDIODa edição aos testes remotos e às correções com IA aprovadasTASTEETLMova dados de olho nos valores

Servidores

TASTEREMOTEUma área de trabalho remota rodando no seu próprio servidorTASTEGEOUm servidor geoespacial compatível com o GeoServer, reconstruído em RustTASTEMAILRetome o controle do seu e-mail

Começar

DownloadsVersões mais recentes de cada produtoDocsComo usar cada produtoComprarAssinaturas e licenças perpétuasTodos os produtosTodos os produtos de relance
Todos os produtos
MarketplaceNotícias
Tecnologia

Notícias

Notícias de desenvolvimento de hojeAnúncios oficiais de linguagens, frameworks, GitHub e IADocumentaçãoGuias de linguagens, frameworks e algoritmos

Linguagens de programação

RustTypeScriptJavaScriptPythonGoC#JavaCC++KotlinDart

Frameworks

Frameworks de front-end webNext.jsReactVue.js · NuxtSvelteKitAngular
Frameworks de servidorSpring BootDjangoFastAPIASP.NET CoreNestJS · Express
Frameworks de apps e desktopTauriFlutterReact NativeElectron

Algoritmos

Fundamentos de algoritmosAnálise de complexidade · Ordenação · Busca · Estruturas de dados básicas · Árvores e heapsAlgoritmos essenciaisBusca em grafos · Caminho mínimo e árvore geradora mínima · Programação dinâmica · Algoritmos gulosos · Divisão e conquista · BacktrackingAlgoritmos avançadosAlgoritmos de strings · Matemática e teoria dos números · Manipulação de bits · Árvores de segmentos · Union-FindAlgoritmos práticosEstratégia para entrevistas de código · Cache LRU · Limitação de taxa · Hashing consistente
Toda a documentação de desenvolvimento
Comunidade
ProjetosDescubra criadores e trabalhosRegistros de desenvolvimentoDecisões e aprendizadosPromptsInstruções reutilizáveisProblemas de ferramentas de IAProblemas e contornos de Claude, Codex, GeminiVitrineResultados concluídosGuia da comunidadeComo construímos em aberto
Colabore
Transferência técnicaApps nativos em Rust e eguiConstrução de site10 idiomas, contas, documentação e downloadsConstrução de app de desktopRust e egui, sem WebViewPipeline de lançamento e pagamentoAssinatura, MSI, deb, rpm, AppImage, hashesParceiro de vendasRecomende e ganhe 30%ContatoDesenvolvimento, parcerias e investimento
Serviços
Área de trabalho remotaAcesse seu computador pelo navegadorPacotes de instalação sob medidaSó o necessário, configurações pré-carregadas
Comprar
PT
한국어EnglishDeutschEspañolFrançaisItalianoPortuguês (Brasil)日本語简体中文繁體中文
Entrar
Entrar
TASTEDEV

De pequenas ferramentas a um desenvolvimento melhor.

support@tastedev.netApoiar TASTEDEV
ProdutosLinha de produtosComprarDocsDownloadsMarketplaceSuporte
ComunidadeProjetosRegistros de desenvolvimentoPromptsProblemas de ferramentas de IAVitrine
PolíticasPolítica de privacidadeTermos de usoTermos de assinaturaReembolsoDiretrizes da comunidade
ContaEntrarCriar conta
Visitantes
Hoje
012345678901234567890123456789012345678901234567890123456789
Ontem
012345678901234567890123456789012345678901234567890123456789
Visualizações totais
0123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789
Empresa
GXSOFT
Representante
CHOI YOUNG GU
Número de registro comercial
853-44-00368
Endereço
9F V24, 351 Gyeongin-ro, Michuhol-gu, Incheon, Republic of Korea
Telefone
+82-10-4404-1523
E-mail
whitecalvin@tastedev.net
Responsável pela privacidade
CHOI YOUNG GU

© 2026 TASTEDEVAs informações dos produtos se baseiam em fontes de desenvolvimento verificadas.Lançado · em melhoria

Documentação de Algoritmos de strings
Algoritmos de strings
ConceptsHow It WorksImplementationComplexityPractice ProblemsReal-World Use
Discussões

Guia de Algoritmos de strings · 4/6

Complexity

Por enquanto, este capítulo está disponível apenas em inglês.

This chapter analyzes time and space in terms of text length n, pattern length m and alphabet size σ. String algorithms often behave very differently on average and in the worst case, so both are covered.

Naive matching

There are n - m + 1 starting positions and up to m comparisons at each, so the worst case is O(n·m). Text aaaa...a with pattern aa...ab is the textbook bad input. On the other hand, with a large alphabet and text that looks random, most attempts fail on the first or second character, so the average is close to O(n). Extra memory is O(1).

Why KMP is linear

KMP's inner while loop looks like a nested loop, yet the total cost is O(n + m). An amortized argument shows why.

  1. k grows by at most 1 per text character, so its total increase is at most n.
  2. Every iteration of the while loop decreases k by at least 1, and k never drops below 0.
  3. Therefore the while loop cannot run more times in total than k ever increased, which is at most n.

The same argument gives O(m) for the prefix function. Space is O(m) for the pi array, and because the text is read strictly left to right, KMP works unchanged on streams.

Counting comparisons makes the difference concrete.

def naive_comparisons(text: str, pattern: str) -> int:
    count = 0
    for s in range(len(text) - len(pattern) + 1):
        for j in range(len(pattern)):
            count += 1
            if text[s + j] != pattern[j]:
                break
    return count


def kmp_comparisons(text: str, pattern: str) -> int:
    pi = [0] * len(pattern)
    k = 0
    for i in range(1, len(pattern)):
        while k > 0 and pattern[i] != pattern[k]:
            k = pi[k - 1]
        if pattern[i] == pattern[k]:
            k += 1
        pi[i] = k
    count, k = 0, 0
    for ch in text:
        while True:
            count += 1
            if ch == pattern[k]:
                k += 1
                break
            if k == 0:
                break
            k = pi[k - 1]
        if k == len(pattern):
            k = pi[k - 1]
    return count


text, pattern = "a" * 10_000, "a" * 99 + "b"
print(naive_comparisons(text, pattern))  # 990100
print(kmp_comparisons(text, pattern))    # 19901

On the same input the naive method makes about 990,000 comparisons and KMP about 20,000. KMP never exceeds 2n comparisons during the scan.

Rabin-Karp

Rolling the hash costs O(1) per window, so hashing is overall. Each hash hit costs an check, so with real occurrences and rare collisions the expected time is . If the modulus is small, or the input was crafted to collide, almost every window needs a check and the worst case becomes . Space is .

Dúvidas sobre este capítulo?
Capítulo anteriorImplementationPróximo capítuloPractice Problems
O(n + m)
O(m)
occ
O(n + m + occ·m)
O(n·m)
O(1)

Rabin-Karp shines when you look for many patterns of the same length. Put the pattern hashes in a set and each window needs one set lookup, so k patterns cost O(n + k·m) expected time.

def multi_rabin_karp(text: str, patterns: set[str], base: int = 911382323, mod: int = (1 << 61) - 1) -> list[tuple[int, str]]:
    m = len(next(iter(patterns)))
    assert all(len(p) == m for p in patterns)
    def h(s: str) -> int:
        v = 0
        for ch in s:
            v = (v * base + ord(ch)) % mod
        return v
    wanted = {h(p) for p in patterns}
    high = pow(base, m - 1, mod)
    out, cur = [], h(text[:m])
    for i in range(len(text) - m + 1):
        if cur in wanted and text[i:i + m] in patterns:
            out.append((i, text[i:i + m]))
        if i + m < len(text):
            cur = ((cur - ord(text[i]) * high) * base + ord(text[i + m])) % mod
    return out


print(multi_rabin_karp("the cat sat on the mat", {"cat", "mat", "dog"}))
# [(4, 'cat'), (19, 'mat')]

Tries

Insert, lookup and walking to a prefix all cost O(L) for a key of length L, no matter how many words are stored. Autocomplete adds the number of nodes visited while collecting results. With N total characters there are at most N nodes, so space is O(N·σ) with fixed-size child arrays or O(N) with hash maps. When words share few prefixes the node count explodes, which is why compressed tries (radix trees) merge chains of single-child nodes.

A sorted list plus binary search also answers prefix queries, and uses far less memory when the word list rarely changes.

import bisect

words = sorted(["car", "cart", "cat", "dog", "dot"])
lo = bisect.bisect_left(words, "ca")
hi = bisect.bisect_left(words, "cb")   # the next prefix after "ca"
print(words[lo:hi])  # ['car', 'cart', 'cat']

Comparison

AlgorithmPreprocessingSearch (worst)Search (typical)Extra spaceNotes
NaivenoneO(n·m)near O(n)O(1)simplest to write
KMPO(m)O(n)O(n)O(m)never rereads the text
Z-algorithmO(n + m)O(n + m)O(n + m)O(n + m)short code, many uses
Rabin-KarpO(m)O(n·m)O(n + m)O(1)many patterns, substring hashing
Boyer-Moore familyO(m + σ)O(n·m)can be sublinearO(m + σ)fast for long patterns, large alphabets
Aho-CorasickO(total pattern length)O(n + matches)sameproportional to patternsmany patterns in one pass
TrieO(N)O(L) per querysameO(N) to O(N·σ)dictionary prefix lookup

Summary

  • KMP and Z are linear even in the worst case; the amortized argument bounds total decreases by total increases.
  • Rabin-Karp is linear in expectation but can degrade to O(n·m) under heavy collisions.
  • Trie operations depend only on key length, but memory is costly, so consider radix trees or a sorted list too.

0 comentários

Principais comentáriosMais recentes primeiro

Fazer login · Faça login para deixar um comentário.