I did some benchmarking and GCC's fprintf takes 100 times longer even here compared to MSVC's or clang's function.
Attached is a patch that changes progress printing to use WriteConsole on Windows when stderr isn't redirected to file. That gives consistently fast progress display on all compilers. I also noticed that stopping encoding by keyboard press didn't work when not compiled on Visual Studio, fixed that too.

I also changed the progress printing to happen 4 times less often than originally. I think maikmerten's progress update happened too seldom, it looked buggy when it was so sluggish.

I hope @KevinB52379 can test this and report if things now work correctly.

Hmmm.
[...]

Code: [Select]

  hmp3.case.x64    6.860 ± 0.051   1.41 ± 0.01  
  hmp3.chang.x64   4.850 ± 0.019   1.00      

I did some benchmarking and GCC's fprintf takes 100 times longer even here compared to MSVC's or clang's function.
Attached is a patch that changes progress printing to use WriteConsole on Windows when stderr isn't redirected to file. That gives consistently fast progress display on all compilers. I also noticed that stopping encoding by keyboard press didn't work when not compiled on Visual Studio, fixed that too.

I also changed the progress printing to happen 4 times less often than originally. I think maikmerten's progress update happened too seldom, it looked buggy when it was so sluggish.

I hope @KevinB52379 can test this and report if things now work correctly.

Edit: replaced with static compile.

Though I do wonder how JoshuaChang's clang compile is so fast. Usually GCC has been able to produce faster binaries. And if I compile a clang build with joshua's makefile, I get a slower binary than my GCC compile.

@KevinB52379, what if you discard Foobar2000 as an intermediary for a while and encode right in the terminal using Hyperfine, a cross-platform tool for warming up the system and measuring the execution time of the binaries? For example, @misio discovered and I verified that visualization via VST plug-ins works much slower in Foobar2000 than the same plug-ins in audio editors (DAWs), and surprisingly, interaction with WavPack files turned out to be the slowest.

How come when I click your Hyperfire link it brings me back to this hydorgenaudio Helix thread?
Can you provide a download link to try this? 

Don't confuse @KevinB52379 to much.
Old hmp3 versions work, @JoshuaChang version works within foobar.
A solution at the source is worthwile in this case.

Good to know. There are no longer many options that can cause the issue you are facing. I think antivirus or other security product that scans or sandboxes executables is the only thing that can do this.
The converter in foobar2000 uses very low priority by default and you said you haven't increased it. These encoders don't touch priorities so they do their tasks with leftover cycles. Memory consumption is no different between compiles.

You must have some high priority process(es) running on the same core as the UI processes and steal all the processing power from the UI operations. Or a sandbox goes haywire and consumes all the system memory. Swapping will make machine slow even with SSD.

System hang.  The file progress bar increases, but the files being encoded with foobar2000 never changes, and I never see the elapsed time, estimated time, encoding speed, and the 'pause" and "abort" buttons never appear.

I've managed to compile the binary using visual studio 2022, it runs quite slow at my env
(about 1/3 speed compared to clang version), but you can test if it will hang your system

           Command         Mean [s]      Relative  
 ------------------ ---------------- ------------- 
     hmp3chang.exe    4.890 ± 0.021          1.00  
  hmp3chang_vc.exe   10.558 ± 0.041   2.16 ± 0.01 

I've managed to compile the binary using visual studio 2022, it runs quite slow at my env(about 1/3 speed compared to clang version), but you can test if it will hang your system @KevinB52379 .

Quote from: KevinB52379 on 2024-04-24 12:31:11

System hang.  The file progress bar increases, but the files being encoded with foobar2000 never changes, and I never see the elapsed time, estimated time, encoding speed, and the 'pause" and "abort" buttons never appear.

You keep describing what the problem looks like in Foobar2000 and ignore the suggestion to test Helix MP3 encoder in the terminal. Start encoding one relatively large WAV file (e.g. merge songs from the same album into one WAV file) and describe what you see. The encoder outputs its own status report with various counters.

I think i have the same problem, my cpu is zen2 4650g(6c12t), i got around 280~300x under command line @ single thread with autodidact's clang build or rarewares' gcc build, I also compiled helix myself with clang plus linktime optimization, my version got around 480x. maybe that's the key.
here's the binary, you can try it.

Quote from: JoshuaChang on 2024-04-19 04:13:51

I think i have the same problem, my cpu is zen2 4650g(6c12t), i got around 280~300x under command line @ single thread with autodidact's clang build or rarewares' gcc build, I also compiled helix myself with clang plus linktime optimization, my version got around 480x. maybe that's the key.
here's the binary, you can try it.

To be honest since i did read this i thought you have the same problem as @KevinB52379.
How does foobar multithreaded react on your system with the other builds?

As a sidenote: fast-math + AVX2 gives another nice boost to the fast clang compile.