Editor’s Note: This is the first in a five-part blog series on refactoring and modernizing PHP applications. We’ve all heard the expression from the children’s story: “slow and steady wins the race.” But what does this have to do with refactoring? And how can this help us to modernize our applications? First, a little background: […]

The post Part 1: Slow and Steady appeared first on BrandonSavage.net.

This blog is a guide to learn about a PHP class, properties, methods, inheritance, and constructors.

Truncated by Planet PHP, read more at the original (another 19135 bytes)

The PHP development team announces the immediate availability of PHP 7.2.31. This is a security release.All PHP 7.2 users are encouraged to upgrade to this version.For source downloads of PHP 7.2.31 please visit our downloads page, Windows source and binaries can be found on windows.php.net/download/. The list of changes is recorded in the ChangeLog.

The PHP development team announces the immediate availability of PHP 7.4.6. This is a security release which also contains several bug fixes.All PHP 7.4 users are encouraged to upgrade to this version.For source downloads of PHP 7.4.6 please visit our downloads page, Windows source and binaries can be found on windows.php.net/download/. The list of changes is recorded in the ChangeLog.

Platform.sh now supports displaying activities from your integrations in the API or command line.
This means that from now on, external integrations (GitHub, Gitlab, Slack, etc.) that you enable in your Platform.sh project will trigger activities every time that something happens with that integration.
This makes validating, testing, and troubleshooting an external integration so much easier.
These new activities are already available to users via the API or the CLI, and they will soon be displayed in the Platform.

The front page of the LLVM website proudly claims that:

Clang is an “LLVM native” C/C++/Objective-C compiler, which aims to deliver amazingly fast compiles […]

I’m not sure whether this has been true in the past, but it certainly isn’t true now. Each LLVM release is a few percent slower than the last. LLVM 10 put some extra effort in this area, and somehow managed to make Rust compilation a whole 10% slower, for as yet unknown reasons.

One might argue that this is expected, as the optimization pipeline is continuously being improved, and more aggressive optimizations have higher compile-time requirements. While that may be true, I don’t think it is a desirable trend: For the most part, optimization is already “good enough”, and additional optimizations have the unfortunate trend to trade large compile-time increases for very minor (and/or very rare) improvements to run-time performance.

The larger problem is that LLVM simply does not track compile-time regressions. While LNT tracks run-time performance over time, the same is not being done for compile-time or memory usage. The end result is that patches introduce unintentional compile-time regressions that go unnoticed, and can no longer be easily identified by the time the next release rolls out.

Tracking LLVM compile-time performance

The first priority then is to make sure that we can identify regressions accurately and in a timely manner. Rust does this by running a set of benchmarks on every merge, with the data available on perf.rust-lang.org. Additionally, it is possible to run benchmarks against pull requests using the @rust-timer bot. This helps evaluate changes that are intended to improve compile-time performance, or are suspected of having non-trivial compile-time cost.

I have set up a similar service for LLVM, with the results viewable at llvm-compile-time-tracker.com. Probably the most interesting part are the relative instructions and max-rss graphs, which show the percentual change relative to a baseline. I want to briefly describe the setup here.

The measurements are based on CTMark, which is a collection of some larger programs that are part of the LLVM test suite. These were added as part of a previous attempt to track compile-time.

For every tested commit, the programs are compiled in three different configurations: O3, ReleaseThinLTO and ReleaseLTO-g. All of these use -O3 in three different LTO configurations (none, thin and fat), with the last one also enabling debuginfo generation.

Compilation and linking statistics are gathered using perf (most of them), GNU time (max-rss and wall-time) and size (binary size). The following statistics are available:

instructions (stable and useful)
max-rss (stable and useful)
task-clock (way too noisy)
cycles (noisy)
branches (stable)
branch-misses (noisy)
wall-time (way too noisy)
size-total (completely stable)
size-text (completely stable)
size-data (completely stable)
size-bss (completely stable)

The most useful statistics are instructions, max-rss and size-total/size-text, and these are the only ones I really look at. “instructions” is a stable proxy metric for compile-time. Instructions retired is not a perfect metric, because it discounts issues like cache/memory latency, branch misprediction and ILP, but most of the performance problems affecting LLVM tend to be simpler than that.

The actual time metrics task-clock and wall-time are too noisy to be useful and also undergo “seasonal variation”. This could be mitigated by running benchmarks

Truncated by Planet PHP, read more at the original (another 18417 bytes)

Zend by Perforce is offering several free hands-on exercises for gaining experiencing with various PHP and Open Source topics. Maintaining skills is important in many professions and especially in Information Technology. Learn more in this blog!

Truncated by Planet PHP, read more at the original (another 17468 bytes)

This episode is sponsored by
Using the WordPress REST API

The post Interview with Derick Alangi appeared first on Voices of the ElePHPant.