@DimonSoft
No language but C/C++ is flexible enough to do what I want. Hearing about other languages when talking about decompression and codecs is weird. Other languages trade development speed for code quality (even C itself, but to a lesser extend), so many tricks are evil for them, comfort is their main reason for existing.

Interpreted and jit languages (python, java, c#, lisp, forth) add an extra delay on executable loading and bring extra dependencies. Golang and D use garbage collection, which introduces an extra pause from time to time. Pascal, delphi and fortran are probably comparable in performance, I'm just too lazy to learn them, they ain't that much better.

I know nothing about those best practices.

They usually prefer simplicity to speed, and it looks stupid to me. It's not what I'm learning C for.

What are best practices on making C libraries? There are probably none, or there are 3 different ways that compete between each other. Such a mess.

By the way, back in 2012 I downloaded a few pieces of pixelart from pixiv. I converted all gif images to png. Most of them became smaller, but a few became bigger instead. Here are those "anomalies".

I don't know what is the cause exactly, I guess gif header is smaller than png header. And not all images benefit from png "vertical compression", the simple horizontal compression from gif is enough for them.

@DimonSoft
No language but C/C++ is flexible enough to do what I want.

Hearing about other languages when talking about decompression and codecs is weird.

Other languages trade development speed for code quality (even C itself, but to a lesser extend), so many tricks are evil for them, comfort is their main reason for existing.

Build systems kinda suck though, I'm working on it.

Interpreted and jit languages (python, java, c#, lisp, forth) add an extra delay on executable loading and bring extra dependencies.

Golang and D use garbage collection, which introduces an extra pause from time to time.

Pascal, delphi and fortran are probably comparable in performance, I'm just too lazy to learn them, they ain't that much better.

They have their uses, but they aren't that necessary for small programs, they actually harm small programs. It's not like anybody cares about that though.

Speed critical code is usually written in C + assembly, it usually pays off to tune it manually.

The thing is, I'm currently studying windows, and my best bet right now is windows provided compilers (that is, C/C++ compiler, visual basic compiler, c# compiler). I can't expect other compilers to provide good support for windows specific things, like structured exception handling.

Wish somebody would pay me for maintaining those libraries.

... (although, as revolution correctly points out every so often, that entirely depends on private implementation details which will absolutely change/regress, without warning!, upon subsequent releases of cpu, compiler, OS, etc. Thus, such "speed results" are temporary and shouldn't be relied upon, instead preferring stable and well-tested algorithms).

Speaking about changes in performance with new CPU releases I’d say that these days a lot of cool and smart tricks that used to be something to boast about <snip> CPU manufacturers optimize for typical code sequences, not for cool tricks.

Especially funny is that most of C[++] optimizations became possible because of undefined behaviour which has always been more a gun to shoot yourself than a useful feature.

DimonSoft wrote:

Especially funny is that most of C[++] optimizations became possible because of undefined behaviour which has always been more a gun to shoot yourself than a useful feature.

<…> show me the numbers!

alexfru wrote:

DimonSoft wrote:

Especially funny is that most of C[++] optimizations became possible because of undefined behaviour which has always been more a gun to shoot yourself than a useful feature.

<…> show me the numbers!

No need to show the numbers. Even the simpliest cases of undefined behaviour like “integer overflow is UB” make it possible to optimize out checks like if (a + 1 > a). Not to mention “NULL pointer dereferencing is UB” which allows an optimizing compiler to optimize out half of your program if you skip a check for NULL.

I haven’t really counted optimizations (they’re somewhat different in different compilers) but really a lot of them do rely on the fact that in cases of UB a compiler is allowed to do anything.

void foo(char* p) {
  if (p) do_something_with(*p);
}
void bar(char* p) {
  if (p) foo(p);
}
    

void foo(char* p) {
  if (p) do_something_with(*p);
}
void bar(char* p) {
  if (p) do_something_with(*p);
}
    

                        GifFileType *gifFile = DGifOpenFileNameW(L"25__5__x256_rgb_a.gif");

                        //NOW
                        //DGifSlurp(gifFile);

                        int number_of_frames;
                        DGifSlurp_firstonly(gifFile, &number_of_frames);

                        int animation_frame = 0;



                        BYTE* p = (BYTE*)ddsd.lpSurface;

                        BYTE* in_cursor = gifFile->SavedImages[animation_frame].RasterBits;

                        GifColorType* Colors;

                        ColorMapObject* ColorMap = gifFile->SavedImages[animation_frame].ImageDesc.ColorMap;

                        if (!ColorMap) goto try_global;

                        Colors = ColorMap->Colors;

                        if (Colors) goto done; //else try_global

try_global:
                                
                        Colors = gifFile->SColorMap->Colors;

done:

                        int pitch_diff;
                        pitch_diff = ddsd.lPitch - ddsd.dwWidth * 4;
                        //LATER: if (is_rgb)

                        if (pitch_diff == 0) {
                                for (int y = 0; y < ddsd.dwHeight; y++) {
                                        for (int x = 0; x < ddsd.dwWidth; x++) {
                                                GifColorType* color = &Colors[*in_cursor++];
                                                *p++ = color->Blue;
                                                *p++ = color->Green;
                                                *p++ = color->Red;
                                                *p++ = 0;
                                        }
                                }
                        } else {
                                for (int y = 0; y < ddsd.dwHeight; y++) {
                                        for (int x = 0; x < ddsd.dwWidth; x++) {
                                                GifColorType* color = &Colors[*in_cursor++];
                                                *p++ = color->Blue;
                                                *p++ = color->Green;
                                                *p++ = color->Red;
                                                *p++ = 0;
                                        }
                                        p += pitch_diff;
                                }
                        }

                        DGifCloseFile(gifFile);    

Everything I'm telling about programming languages are just my personal quirks. My goal is minimal size (just for the hell of it (and for studying the resulted binary)) and using windows specific features properly. If you know of a language that generates windows binaries smaller or equal to 4 kilobytes, let me know.