navigation.md and homepage needs to be updated?

Yes, we need to update README.md and navigation.md. I'd also mention something of the following:

• #pragma GCC optimize("Ofast,unroll-loops") allows more aggressive compiler-level optimisation;
• #pragma GCC target("avx2") allows significant speedupswhen your code can be auto-vectorized, which primarily affects simple for-loops doing linear transforms (primarily, adding one vector to another, multiplied by some constant);
• Doing% is very expensive, try to avoid when possible:
  • When adding or subtracting modints;
  • When multiplying at most two modints, consider keeping them modulo$M^2$, until you really need to get back to modulo$M$;
• Avoid having lots of small containers, likemap<int, int> to[maxn]. If you need to keep a lot of lists, consider keeping a vector ofbasic_string<T> orforward_list<T>, rather than a vector ofvector<T> ordeque<T>;
• When iterating nested arrays, try to avoid iterating over earlier indices in the inner loops (e.g. forA[i][j], ideally,i should be in the outer loop, andj should be in the inner loop);
• Link toMontgomery multiplication;
• Link toAlgorithms for Modern Hardware;
• Link to some other useful blogs on the topic?

I'd also mention something of the following:

I agree with you, but I want to get the simple things down in an article first.

There's still some formatting problems: some C++ keywords are not formatted, the subpoints of the#define section need to be formatted as such.

I'm not convinced we should be pushing a lot of what's currently in the article:

Definingint aslong long is super hacky and likely should not be taught imo.

Theusing namespace std section seems unnecessary.

The statement that C++ is, by default, iostreams doesn't really make sense as one can avoid using them.

Some of the only necessary knowledge is disabling the sync and theendl vs'\n' and flush portion.

There's still some formatting problems: some C++ keywords are not formatted, the subpoints of the#define section need to be formatted as such.

Everything has been formatted afaict. You can highlight specific places that haven't.

I'm not convinced we should be pushing a lot of what's currently in the article:

Definingint aslong long is super hacky and likely should not be taught imo.

Yes it's hacky, so I included a note that it's not recommended. But you may encounter this when looking at other people's submissions.

Theusing namespace std section seems unnecessary.

I think it's important to point out the naming conflicts, which can be confusing.

The statement that C++ is, by default, iostreams doesn't really make sense as one can avoid using them.

You can, but my understanding is that C-style I/O is only provide compatibility with C libraries.

Some of the only necessary knowledge is disabling the sync and theendl vs'\n' and flush portion.

The explanations aren't strictly necessary, but I think it's better to explainwhy than just provide a template for copy-pasting.

@adamant-pwn is the page good enough for a new article? There is a balance between quality control and not getting stuck forever. I think the info as it is currently is more beneficial published and then tweaked later than not having anything on it.

I still think we should implement some of the suggestions from#1383 (comment). We certainly have to updateREADME.md andnavigation.md in any case, as is the process when adding new articles, but I also think that a lot of the other points are very low-effort to add (and can be essentially transfered from the comment), and should not be a reason to get stuck forever.

I agree with@adamant-pwn. No offense but the article seems low effort and no time was put in to improve it. Instead there was another request to "just publish it".

Formatting isn't consistent:

"cout every time you read from cin". No formatting even exists on this line at quick glance.

I'd prefer intro paragraphs on why we need faster io and other topics but I sort of feel at this point that there's potentially too much time reviewing relative to the effort of the article.