(dramatic whoosh)
- Why are fast tokenizers called fast?
In this video, we'll see exactly how much faster,
also, so-called fast organizers are compared
to their slow counterparts.
For this benchmark, we'll use the GLUE MNLI dataset
which contains 432,000 spells of text.
We'll see how long it takes for the fast and slow versions
of a BERT tokenizer to process them all.
We define our fast and slow token organizer
using the AutoTokenizer API.
The fast tokenizer is a default when available.
So we pass along, use_fast=False to define the slow one.
In a notebook, we can time the execution
of itself with a time magic command, like this.
Processing the whole data set is four times faster
with a fast tokenizer.
That quicker indeed, but not very impressive.
This is because we passed along the texts
to the tokenizer one at a time.
This is a common mistake to do with fast organizers
which are backed by Rust, and thus able to prioritize
the tokenization of multiple texts.
Passing them only one text at a time,
is like sending a cargo ship between two continents
with just one container, it's very inefficient.
To unleash the full speed of our fast tokenizers,
we need to send them batches of texts, which we can do
with the batched=True argument of the map method.
Now those are impressive results, so the fast tokenizer
takes 12 second to process the dataset that takes four
minute to the slow tokenizer.
Summarizing the results in this table,
you can see why we have called those tokenizers fast.
And this is only for tokenizing texts.
If you ever need to train a new tokenizer,
they do this very quickly too.