Sublime Forum

Turn on basic python optimizations via PYTHONOPTIMIZE?

#1

ST doesn’t turn on basic python optimizations via -0 and -00 options. It’s also not possible turn them on via environment variable PYTHONOPTIMIZE. This means the __debug__ constant is always true and assert statements are not disabled/stripped in production releases.

I’m wonder if this is an oversight or is it expected functionality?

1 Like

#2

Nice question. I hope we can have the -O flag enabled during normal execution of Sublime in the future, while not enabled when running with --debug.

0 Likes

#3

:+1: to enabled when running via --debug.

It could also be configurable via environment variable PYTHONOPTIMIZE. You could run two builds using UnitTesting plugin, one with it enabled, and one disabled.

0 Likes

#4

… bump?

1 Like

#5

I think especially considering that assert statements are skipped (which are usually run in the default configuration) could be a significant downside of this change since plugin code might depend on it.

Do you have any data about the actual improvement on performance with the various optimization flags? The last thing I remember was that they are quite insignificant.

0 Likes

#6

I’ve no idea what the performance improvements are. I’m reluctant to use or add assertions because they’re not compiled out.

In terms of dependencies. I’ve thought about this.

The vast majority of plugins don’t use assertions: completions, snippets, colors schemes, themes, etc. don’t even use python so it doesn’t impact them at all. Most other plugins don’t use assertions so they’re not impacted.

For the remainder, because of the nature of assertions (“Assert statements are a convenient way to insert debugging assertions into a program”) most who are using them will be using correctly so any issues are probably bugs or design issues. For example they’re used in NeoVintageous, I had one issue when I stripped them all out and it was a test issue i.e. the test was asserting that the code raised an assertion exception. This is a design issue. It was just one.

There will be some plugins that have issues, too few I think. There are also ways to alleviate this issue.

  • First: open up the environment variable so that developers can start testing their plugins with the optimizations enabled. Devs can potentially run two builds with UnitTesting (if they using it), one with the optimisations disable and one enabled to catch any potential issues (but this probably isn’t necessary).
  • Explain in the changelog the change and that in some already decided future release, the optimizations will be enabled. At least 1 GA cycle. I don’t think it needs more than that, because as I said earlier I don’t think the impact is big. Example: the next build allows us to manually enable the optimizations while developing, the next GA release explains that the following GA release will default to enable optimizations, and then the dev build after the next GA release enables them to catch any remaining issues leading up to that GA. That might seem like not a lot of time, but I really do think that too few plugins will have issues.

It also depends on which or if both optimizations are enabled. -0 which enables the assert optimizations will raise so few issues that I don’t think it matters much. The -00 impacts any plugin using doc strings. It possible that are some plugins out there that depend on them. Introducing both the optimizations could be done over several GA releases i.e. -0 first then -00 in the one after that.

Note: __debug__ will be set False if either of the optimizations are enabled. I’d like see to both enabled. It looks like there is a memory improvement by -00 becasue it strips out the docstrings.

0 Likes

#7

I’d be pretty hesitant to change the run-time environment so drastically years into the development of packages that work on ST3.

0 Likes

#8

Tracker issue: https://github.com/SublimeTextIssues/Core/issues/2139

0 Likes