search

4ian / GDevelop

🎮 Open-source, cross-platform 2D/3D/multiplayer game engine designed for everyone.
https://gdevelop.io
Other
10.81k stars 848 forks source link

gd::FileStream is slow #317

Closed victorlevasseur closed 7 years ago

victorlevasseur commented 7 years ago

Probably introduced by #312. But still surprising because I remember having fixed a bug causing that prior to merge the PR. It still seems that gd::FileStream fails closing preventing a further open call on the same stream, especially on Windows.

4ian commented 7 years ago

Are you able to do a git bisect to be sure that this was introduced by the new stream, or have you identified the cause of the failure? :)

victorlevasseur commented 7 years ago

There's no bug. The user reported that the game produced was incomplete but it was because he stopped GDevelop before the end of the export as he thought GDevelop was freezing. A side effect of the new gd::FileStream is that the stream or the opening (I don't know) is far slower on Windows, causing a bigger delay when exporting a native game.

victorlevasseur commented 7 years ago

We need to find a way to report the progress on the .edg file creation (like it's done for the other steps of the compilation). Maybe a lambda passed as an argument to DatFile::create will do the trick.

4ian commented 7 years ago

Ok! How long is the delay?

4ian commented 7 years ago

Do you know why the stream is so much slower?

victorlevasseur commented 7 years ago

It may be slow on opening as I have to construct the filebuf each time. This is almost required on Windows as only the filebuf ctor can take a FILE argument (it's a MinGW extension that allows that). I'll try to optimize this as there might be a possibility of just changing the FILE handle. On Linux, I can certainly optimize by not changing the filebuf. To do so, I'll probably completely separate the two implementation so that it's easier to read.

EDIT: With the small benchmarks I made, gd::FileStream is currently 50 times slower than std::fstream on Linux but is almost as fast as std::fstream on Windows. :o So there's something else wrong on Windows.

victorlevasseur commented 7 years ago

Found the problem. It was the writing, fixed in 880ccad. I don't remember how I ended up putting 1 as the buffer size of the internal filebuf on Windows, causing a write operation for each byte written in the stream. Removing this and letting the default argument as buffer size solved the problem (it's even 1.04 times faster than the standard fstream on Windows :o ).

4ian commented 7 years ago

Great job! :)