performance issue in v2.1.0 ?

[jgb]

Hello,

when upgrading from v2.0.0 to v2.1.0 our suite of pytests which usually takes around 10 minutes, runs for many hours without finishing.
I've narrowed it down to the fact that upgrading to v2.1.0 of libfaketime seems to be the cause.

Any idea what might be going on here?

Greetings,

jgb

[azmeuk]

Hi. Thank you for the report.
For additional context, on which system do you run your testsuite? Do you observe the same behavior on different systems?
We updated the underlying libfaketime version as well as changing a bit of code. To be sure of which one is causing the issue, would you try to run your testsuite, with the current python-libfaketime codebase, and the previous libfaketime version?

git clone https://github.com/simon-weber/python-libfaketime.git
cd python-libfaketime
git clone https://github.com/simon-weber/libfaketime.git libfaketime/vendor/libfaketime
make -C libfaketime/vendor/libfaketime

Then install this version in your project environment and run your testsuite:

cd your/project/path
pip install the/path/to/python-libfaketime -U --force
pytest

[jgb]

@azmeuk thanks, I did what you asked, and then I don't observe the performance regression.
This is on Ubuntu 24.04 LTS with python 3.12.

[vlaci]

I've run into the same issue. I could work around by setting FAKETIME_FORCE_MONOTONIC_FIX to 0.

[azmeuk]

@vlaci what is your OS?
@jgb do you confirm FAKETIME_FORCE_MONOTONIC_FIX make a change for you?

If so, I don't know if we would want to enable it by default, as it is discouraged by the libfaketime documentation:

  Please try to avoid compiling with FORCE_MONOTONIC_FIX on platforms that
  do not need it. While it won't make a difference in most cases, depending
  on the specific FAKETIME settings in use, it would cause certain
  intercepted functions such as pthread_cond_timedwait() return with a
  time-out too early or too late, which could break some applications.

[jgb]

@azmeuk I can confirm, just tested v2.1.0 with FAKETIME_FORCE_MONOTONIC_FIX=0, that brings performance back to a normal level. Without that exported variable, performance becomes a disaster.

[azmeuk]

@simon-weber do you have any opinion about disabling FAKETIME_FORCE_MONOTONIC_FIX by default?

[vlaci]

@vlaci what is your OS? @jgb do you confirm FAKETIME_FORCE_MONOTONIC_FIX make a change for you?

If so, I don't know if we would want to enable it by default, as it is discouraged by the libfaketime documentation:

  Please try to avoid compiling with FORCE_MONOTONIC_FIX on platforms that
  do not need it. While it won't make a difference in most cases, depending
  on the specific FAKETIME settings in use, it would cause certain
  intercepted functions such as pthread_cond_timedwait() return with a
  time-out too early or too late, which could break some applications.

I am on NixOS (Linux) with glibc 2.39

[simon-weber]

It looks like this may be a regression in libfaketime 0.9.10. Maybe we downgrade our vendored libfaketime instead? From a quick look over the FORCE_MONOTONIC_FIX discussions I'm not sure about the safety of disabling it.

[azmeuk]

@jgb @vlaci can you check if #82 solves the issue for your use cases?

[jgb]

@jgb @vlaci can you check if #82 solves the issue for your use cases?

hello, I tried, but it fails to build / install...

[azmeuk]

@jgb What error message do you see?
Did you install with pip install git+https://github.com/simon-weber/python-libfaketime@refs/pull/82/head?

[jgb]

@jgb What error message do you see? Did you install with pip install git+https://github.com/simon-weber/python-libfaketime@refs/pull/82/head?

Sorry, I must have done something wrong initially, using your command it installed just fine.
Tried it out just now, even though the result isn't as bad as it was, it still makes my test suite go from taking 5 minutes before, and now 12+ minutes.
Also it makes about 20 of my tests fail, which don't fail using v2.0.0 and those failing tests are all related to selenium + chrome...

[vlaci]

@jgb @vlaci can you check if #82 solves the issue for your use cases?

I can confirm that the PR works. It indeed looks a bit slower. In my case, it's about 10%