On the Laravel News site, they've posted the announcement of the release of the results from their 2018 edition of the Laravel Survey.

We partner with LaraJobs to run an annual Laravel survey to see what types of projects people are taking on with Laravel as well as get some feedback on what the Laravel community could be doing better. The results ended up with over 1,500 submissions, and some interesting insights.

You can see the complete results on this 2018 Laravel Survey Results page and thanks for everyone who took the time to fill it out.

Questions asked in this year's survey included topics such as why they selected Laravel, size of projects, if they're able to find the developers they need and what they'd like to see more of in the Larvel community (tutorials, articles, regional conferences, etc).

Phoronix has a new post to their blog sharing some benchmark results for PHP 7.3, the next major language release, and things are looking positive!

Released on Thursday was PHP 7.3 RC6 as the last planned pre-release for the upcoming PHP 7.3. Here are some benchmarks looking at the PHP 7.3 performance compared to PHP releases going back to the v5.5 series on a Linux server.

[...] I ran some fresh benchmarks over the past day on PHP 5.5.38, PHP 5.6.38, PHP 7.0.32, PHP 7.1.24, PHP 7.2.12, and the PHP 7.3.0-RC6 test release. [...] PHP 7.3 is just shy of 10% faster than PHP 7.2 in the popular PHPBench. PHP 7.3 is 31% faster than PHP 7.0 or nearly 3x the speed of PHP5.

The post includes more benchmarks that reinforce this same trend with both the Zend performance testing and their own testing framework.

Overall, PHP 7.3 is shaping up to be another notable upgrade to the PHP7 series for its continued performance improvements, the new PHP FFI interface, and other new additions for this PHP release due out in early December.

Nikola Posa has a new post to his site sharing what he calls a "community-driven PHP 8 wishlist" as gathered from replies to a tweet he posted back in July 2018.

It's been over two months since I started a research on Twitter about the things that developers would like to be added or improved in the next major PHP release. [...] It had a surprisingly long reach, inspiring developers, prominent experts, community representatives to express their opinion through more than a hundred responses.

It would be a waste to leave such a valuable data in the form of a raw and fuzzy Twitter thread, so I finally found some time to turn it into something more useful.

In the post he shares the results in a spreadsheet, with the top three being: arrow functions, multi-threading and method overloading. Other interesting features also made an appearance pretty high on the list including boot-time preloading, scalar objects, native async and built-in request/response objects. Check out the post for the complete list and how it was processed into its final form.

On the Exakat blog there's a new post covering some of the impact that PHP versions have on codebases they've reviewed in the normal course of their product's analysis and the requirements of Open Source software.

With the upcoming PHP 7.3, the question of the next migration is back on our tables. We’ll hear a strange mix of begging to move to the new versions for features and security, mixed with a constant threatening that some old versions will soon be unmaintained or worse. Indeed, there is versions impact on PHP code bases.

Particular witnesses of that evolution are open source projects. They usually have to support a wide range of versions, and in the same time, are actively encouraged to use the newest features. It is a delicate work of balancing compatibility and progress.

To observe the way Open Source projects handle the evolution of PHP, we have audited 1977 Open source PHP projects, by linting them with PHP versions from 5.5 to 7.3. This taught us the impact of PHP on code, over a long period of coding. Let’s review them.

The post starts by talking about linting of PHP files (checking the syntax for issues but not executing the contents). It then shares some statistics about the number of Open Source projects that lint on every build and how it has trended over time. They also share some results on the age of packages that are in wide use, showing that the ration of "old code" to "young code" is surprisingly similar.

Jason McCreary, creator of the Laravel Shift service that makes it easier to upgrade your Laravel code to new versions, has a new post to his site where he shares Laravel "by the numbers", some statistics based on the use of the service.

I had the privilege to speak at Laracon again this year. The last Laracon talk I gave, Practicing YAGNI, is one I am most proud of. Initially, I wanted to do a continuation on this topic. But there were some other talks on related topics. So I thought, “what can I talk about that’s unique to me”.

The answer was Laravel Shift. As the creator of Shift I have a unique insight into Laravel apps.

I’m super sensitive about sounding salesy. I don’t want to talk about Shift itself. I want to talk about the data derived from Shift.

The statistics are based on around 8500 Laravel applications currently using the service. He shares the results for:

• Most popular Laravel version
• Most popular packages
• Most changed file(s)
• Custom namespacing

Along with these basic numbers, he also shares information about project structures, inheritance injection, facade "abuse", queries in views (using models) and many others. Check out the full post for details on these and other results.

In a new post Larry Garfield suggests and interesting approach to arrays in PHP: stop using associative arrays (or at least "basically never").

The other day I was working on some sample code to test out an idea that involved an object with an internal nested array. This is a pretty common pattern in PHP: You have some simple one-off internal data structure so you make an informal struct using PHP associative arrays. Maybe you document it in a docblock, or maybe you're a lazy jerk and you don't. (Fight me!) But really, who bothers with defining a class for something that simple?

But that got me wondering, is that common pattern really, you know, good? Are objects actually more expensive or harder to work with than arrays? Or, more to the point, is that true today on PHP 7 given all the optimizations that have happened over the years compared with the bad old days of PHP 4?

So like any good scientist I decided to test it: What I found will shock you!

He starts by describing his test environment (a local environment, not a cloud one) and the code for his baseline tests. The code generates an array of one million items where each item is an associative array of an integer/string combo. He wants to see what kind of memory consumption is involved in the creation and processing of this data set via sorting. His second test evaluated the serialization size (again, code provided) again checking the memory consumption. He shares the results of these tests and then moves on to similar tests on:

• stdClass instances
• objects with public properties
• objects with private properties
• anonymous classes

The post ends with a summary showing the results of all tests side-by-side with some interesting results (but you'll have to check out the post for yourself if you want to see those).

In a new post to the Exakat blog they try to answer the question "how many parameters is too many" when it comes to the structure of the methods and functions in your application.

Now, that is a classic question, that is often a minefield for anyone writing an increasing long list of argument in a method, or simply trying to set up auditing tools.

Obviously, the answer is not immediate. Parameters may be needed, but on the other hands, currying functions allows to reduce the amount of parameter to one for every function. In between, probably exists a reasonable level that is a golden rule, and also very elusive. So, we decided to check the current practice in PHP code.

They started the research with some of PHP's own native functions that took in specific arguments, ignoring those that took an arbitrary number. Next they made a survey of 1900 open source projects to determine the common practice for parameters by function. The results showed that methods without at least one parameter were "less useful" and that a seemingly reasonable amount of parameters is 5. The post finishes with a spotlight of two they found during their research that had the most parameters: a generated class for database interaction and a dependency injection class.

On the Forma-Pro.com blog there's a new post from Maskim (their Chief Architect) comparing PHP AMPQ libraries including some benchmarks of their performance of their handling of messages.

Increasing popularity of AMQP interop prompted a wave of questions regarding which adapter is the fastest. In this post, I am going to share my findings of message publishing performance. There will be a similar post about consumption side.

He compares three of the main libraries: php-amqplib, amqp-ext and bunny (as well as their adapters for interoperability). To get a good comparison he's also thrown in one written in Golang for external comparison. He start be outlining the system specs he used for testing and then various graphs of the benchmark results. The results of his benchmark script are interesting with only a few oddities here and there. The post finishes with a summation of the results but you'll have to head over there to see those results.

The Laravel News site has a new post today sharing the results of the 2017 Laravel survey posted a while back. The survey asked the Laravel (and non-Laravel) community about the framework, what they like about it and what they'd like to see in the future.

Back in September, we partnered with LaraJobs to run a Laravel survey to see what types of projects people are taking on with Laravel as well as get some feedback on what the Laravel community could be doing better. The results ended up with over 2,700 submissions and some interesting insights.

You can see the complete results on this 2017 Laravel Survey Results page and thanks for everyone who took the time to fill it out.

The results include answers to questions like:

• why Laravel was selected over others
• what size projects it was being used for
• if you were able to find the Laravel developers needed (and of the right quality)
• size of the business using the framework

Check out the full results for answers to these and other questions from the survey.

On the Trivago Tech blog they've shared some of their experience in continuous performance improvements in PHP applications and how the Blackfire.io service helped them get their best performance.

Our mission is to provide the user with the ideal hotel at the lowest rate. Our backend consists of several services written in different languages. To succeed at this goal we do complex tasks in our main application developed in PHP. While doing this we need to keep the website as fast as possible.

We started to look for some tool that could help us identify performance issues in our code base. We evaluated Blackfire and decided that it was a good fit for our use case.

The article starts by answering the question of "why Blackfire?" and continues on, showing how they integrated it with their workflow. They use the SaltStack tooling to set up servers and configure them so it was just a matter of integrating the Blackfire agent and probe extension via that. They include an overall diagram of how it fits into the architecture and how they worked around the lack of Bitbucket server support. The post finishes with some examples of performance metrics from before and after the optimizations from their results stored in InfluxDB.