3v4l.org

run code in 300+ PHP versions simultaneously
<?php $message = "<p>This is more tricky than it may sound.</p> <p>The problem is that when a unit is unspawned it is immediately deleted. After that we can't report any events about the unit to the script because the unit no longer exists and we don't want to pass references to dead objects to the script.</p> <p>So when the physics system some time after the unspawn detects that the object has left the trigger we have no way of notifying the script about that.</p> <p>There are some potential ways of solving this problem:</p> <ul> <li>We could delay deleting the unit for a "couple of frames" until we have had time to report events about it to the script. However, this would create a new strange state for units to be in, an <em>(about-to-be-deleted)</em> state. This will severely increase code complexity and confusion since there would be a ton of places where you would have to check if you were dealing with a "real" unit or an "about-to-be-deleted" unit, both in the script and in the engine. Horrible.</li> <li>We could add a new event for the triggers <em>Destroyed</em>. The event would be triggered whenever something inside the trigger was destroyed. The event would not pass the unit (because the unit would be destroyed by the time it was triggered). In this way, you could react to the <em>Destroyed</em> message and act appropriately (e.g., scan your list of units inside the trigger for any deleted units). This still wouldn't give you the Enter/Leave symmetry that you perhaps want... instead you would get Enter/Destroy. And you wouldn't be able to tell which unit was destroyed.</li> <li>We could try to keep track of which units are inside which triggers (outside the physics system), so that when you called <em>unspawn()</em> we could immediately generate <em>Leave</em> events for the triggers, before destroying the unit. This would give you a <em>Leave</em> event with a working unit variable. However, tracking all of this would have a performance cost. Also, we still wouldn't have a perfectly symmetric solution, because this <em>Leave</em> event would be triggered immediately when <em>unspawn()</em> was called, unlike other trigger events that are triggered when we do a physics update.</li> </ul> <p>None of these solutions seem really good to me. I'm not so found of implementing a bad solution, because once we have implemented something we have to keep supporting it or break backwards compatibility, which means that if we pick a bad solution we could be stuck with it for a long time.</p>"; $message = preg_replace("/<\/p>((.|\n)+?)(?=<\/p>)/", "\n$1", $message);

Here you find the average performance (time & memory) of each version. A grayed out version indicates it didn't complete successfully (based on exit-code).

VersionSystem time (s)User time (s)Memory (MiB)
5.4.320.0050.03812.50
5.4.310.0070.04312.50
5.4.300.0090.04312.49
5.4.290.0080.04112.49
5.4.280.0060.03412.39
5.4.270.0060.04212.39
5.4.260.0060.04712.39
5.4.250.0040.03812.39
5.4.240.0080.04012.39
5.4.230.0100.05212.38
5.4.220.0060.03812.38
5.4.210.0050.03512.38
5.4.200.0070.04212.38
5.4.190.0040.03912.38
5.4.180.0020.04412.38
5.4.170.0080.03812.38
5.4.160.0050.03712.38
5.4.150.0060.03612.38
5.4.140.0030.04212.07
5.4.130.0070.03512.05
5.4.120.0070.03412.02
5.4.110.0090.03112.01
5.4.100.0050.03512.01
5.4.90.0060.03512.01
5.4.80.0040.03712.01
5.4.70.0030.03812.00
5.4.60.0060.03812.01
5.4.50.0090.04312.01
5.4.40.0060.03512.00
5.4.30.0080.03311.99
5.4.20.0090.03211.99
5.4.10.0070.03411.99
5.4.00.0040.03911.48
5.3.290.0080.04212.80
5.3.280.0070.03912.71
5.3.270.0050.04212.72
5.3.260.0060.03912.72
5.3.250.0080.04412.72
5.3.240.0040.03812.72
5.3.230.0070.03912.70
5.3.220.0060.04512.68
5.3.210.0100.03512.68
5.3.200.0050.03812.68
5.3.190.0090.03412.68
5.3.180.0080.03412.67
5.3.170.0110.03212.66
5.3.160.0040.03812.68
5.3.150.0080.03512.68
5.3.140.0040.03812.66
5.3.130.0040.04012.66
5.3.120.0070.03712.66
5.3.110.0100.03612.66
5.3.100.0100.03312.12
5.3.90.0080.04112.08
5.3.80.0060.03512.07
5.3.70.0080.03812.07
5.3.60.0070.03512.06
5.3.50.0070.03512.00
5.3.40.0030.03912.00
5.3.30.0040.03611.95
5.3.20.0070.03411.73
5.3.10.0090.03211.70
5.3.00.0070.03411.68
5.2.170.0040.0319.19
5.2.160.0040.0299.19
5.2.150.0030.0319.18
5.2.140.0030.0319.18
5.2.130.0060.0289.14
5.2.120.0020.0319.14
5.2.110.0040.0299.15
5.2.100.0060.0269.15
5.2.90.0060.0329.14
5.2.80.0040.0319.14
5.2.70.0080.0269.14
5.2.60.0040.0309.10
5.2.50.0030.0319.07
5.2.40.0020.0309.04
5.2.30.0050.0289.01
5.2.20.0060.0279.01
5.2.10.0070.0548.93
5.2.00.0030.0308.79
5.1.60.0060.0308.07
5.1.50.0040.0268.07
5.1.40.0060.0378.05
5.1.30.0080.0238.40
5.1.20.0040.0328.42
5.1.10.0030.0308.15
5.1.00.0050.0238.15
5.0.50.0060.0176.63
5.0.40.0030.0246.49
5.0.30.0030.0316.30
5.0.20.0030.0196.27
5.0.10.0040.0196.24
5.0.00.0040.0296.24
4.4.90.0050.0194.78
4.4.80.0020.0164.75
4.4.70.0030.0164.76
4.4.60.0040.0144.75
4.4.50.0020.0254.77
4.4.40.0030.0324.71
4.4.30.0010.0174.76
4.4.20.0040.0144.84
4.4.10.0040.0144.85
4.4.00.0030.0244.76
4.3.110.0030.0154.67
4.3.100.0040.0134.66
4.3.90.0050.0184.63
4.3.80.0050.0294.59
4.3.70.0060.0174.63
4.3.60.0050.0134.63
4.3.50.0040.0174.63
4.3.40.0070.0244.53
4.3.30.0040.0213.29
4.3.20.0000.0223.26
4.3.10.0010.0163.22
4.3.00.0030.01715.63

preferences:
141.64 ms | 1394 KiB | 7 Q