What I did was create my own content manager system but for glyphs.
Basically 3 structs. Glyph, glyphset and Fontmanager.
The Glyph struct stores the individual glyph.
glyphset keeps all the glyphs in a single set of a font. Such as if you had X font, size, bold or italic… one that differs slightly can be stored in a different set.
The fontmanger is responsible for loading and storing the sets and deleting them at the end of the program.
When it comes to performance glyphs are each individual texture. So if you just display them the way they appear in a line you will take a performance hit. You will get improved performance by stepping through them alphabetically. (Batching)
There is another alternative rather than storing the glyphs as textures you could store them as surfaces. this has a number of advantages. You can easily manipulate the color of them. You could render copy them yourself to a surface and then display the single surface to screen. In my case I would do that off on another thread.
opengl can give you an advantage when it comes to performance. You have access to instancing not just batching. It is also more friendly to multithreading. SDL2 appears from what I can tell to have some threading involved in its renderer system. you can run into issues were threads can conflict with that thread and actually slow stuff down.
To give you an idea how much batching can make a difference. I sent 40,000 circles bouncing across my screen. 5 different colors. Using batching I got over 60 fps. Swap back forth between circles instead of batching and it drops to 25fps. Even when I batched at 1000 circles it still gave me 60fps.
Anyway hope that helps.