Bug#907057: neverball: Constant fsync calls seriously degrade performance

[Uoti Urpala]

On Wed, 2018-08-29 at 15:27 +0200, Markus Koschany wrote:
> Am 29.08.2018 um 15:08 schrieb Uoti Urpala:
> > If FPS stays sufficiently high that it's not a visible issue, you could
> > try running the binary under strace for example and verify that there
> > are lots of fsync calls while playing. (The calls probably aren't good
> > for the SSD either, even if they don't prevent playing the game.)
> > strace -e fsync -o /tmp/file neverball
> 
> My point is that it isn't something most players would experience as a
> serious performance penalty. The game hasn't changed in years, so either
> it is not perceived as something really serious by many or there is a
> recent regression in libphysfs. Then it should be fixed there.

I'm pretty sure it is a regression - years ago SSDs were not that
common. And even if "most players" use it on machines with an SSD
storing the save directory, the constant fsyncs likely increase SSD
wear, so it's not harmless there either.


> > > Not using libphysfs would be a workaround and not a fix. Hence I am
> > 
> > I'm not sure why you're saying this. Given that upstream Neverball has
> > also stopped defaulting to libphysfs use, it seems like a quite
> > reasonable solution.
> 
> Sure, not using your car when the tires are flat and instead going to
> work by train is a reasonable solution, if you don't want to be late.
> Most people will still want to fix the tires though because that's the
> issue at hand.

That comparison seems wrong. It assumes there are reasons you'd want to
go back to the car (physfs) eventually. Given that upstream has changed
the default, it's not an appropriate comparison here.


> > AFAIK the version currently in Debian can be built with libphysfs
> > disabled too. "Not actionable" seems like an exaggeration, even without
> > packaging a new non-release version.
> > 
> > I just ran a quick test, and building without libphysfs-dev worked with
> > "git checkout neverball-1.6.0; make -j 6 ENABLE_FS=stdio".
> 
> By not actionable I meant that upstream should do a proper release. This
> is not something Debian can do. When they did that, we and all other

However, changing the Neverball build configuration should be well
within what is actionable by Debian.

> distributions would package the new release. It is absolutely not clear
> whether they consider all there other changes as feature complete. In
> the worst case, we fix this bug but open a can of worms for other users.
> Yes, usually it is not as bad for games but surely for other software in
> the archive. There is also a good reason for using fsync. It protects
> you against data loss.

Cases where fsync() is the right tool are actually pretty rare. And
this absolutely isn't one of them (particularly the Neverball save file
case, but more generally physfs doing fsync() calls when the
application hasn't explicitly requested them is not right either).