通过 WebAssembly 在浏览器运行 PHP

file

演示地址:PIB: PHP in Browser,你可以在上面运行PHP代码,然后通过复制地址栏分享代码。

项目地址:oraoto/pib

某天晚上,在看Emscripten的文档,发现Emscripten有emconfigureemmake,可以直接用Emscripten替换编译器实现项目移植,灵光一现就有了这个项目。

性能测试

Firefox和Edge加载更快,用户体验要比Chrome好一点 :)

首先娱乐测试一下,改自eechen的测试,10万的数组填充和字符串拼接:

<?php

$start = microtime(true);

$arr = [];

for ($i = 0; $i < 100000; $i++) {
    $time = microtime(true);
    $arr[$i . '_' . $time] = $time;
}

echo (microtime(true) - $start) . PHP_EOL;

点我直接跑一下

我的电脑CPU是i5-6400,Chrome 66耗时0.35秒,Firefox耗时0.25秒,而原生PHP 7.2只需0.048秒,也就是说性能大约是原生PHP 7.2的1/7左右。

跑PHP源代码自带的Zend/bench.php

simple             0.288
simplecall         0.088
simpleucall        0.226
simpleudcall       0.241
mandel             1.138
mandel2            1.251
ackermann(7)       0.221
ary(50000)         0.037
ary2(50000)        0.033
ary3(2000)         0.626
fibo(30)           0.855
hash1(50000)       0.067
hash2(500)         0.084
heapsort(20000)    0.264
matrix(20)         0.285
nestedloop(12)     0.444
sieve(30)          0.178
strcat(200000)     0.043
------------------------
Total              6.369

而原生PHP 7.2只要0.591秒,差了近11倍。

功能测试

因为是直接编译PHP解析器,所以语言层面的大部分功能都是支持的,目前已知不支持的只有Generator(已支持)。

可以试试PHP7的新特性:

库函数方面支持比较少,默认只编译了datepcrebcmathctypejsonReflectionSPLtokenizerstandardCore这些扩展。

实现原理

原理并不复杂,就是用Emscripten把PHP解释器编译到WebAssembly,然后通过JavaScript调用Zend的API。

为了能让PHP解释器编译成功,需要对代码做少量修改,主要是文件系统相关的两处代码,我只直接注释掉或者return跳过代码。

对比现有方案

3v4l这种在服务端执行代码然后返回结果到前端的方案已经很成熟,在运行和分享PHP代码方面,PIB的优势就是省去了我部署服务器的钱(文件都在Github pages)。

也有其他的在浏览器直接运行PHP的方案:

  • php2wasm:直接把PHP代码编译成wasm,现在还不成熟
  • pyhp.js:用Pyton实现PHP解释器(PyHP,据作者说性能比PHP7好),然后再把这个解释器编译到JS,支持的特性有限,作者已经弃坑

而PIB已经支持了大部分PHP语言特性,不过性能和稳定性仍需提高。

未来

一开始设想是用PHP进行前端开发的,但是实现不容易,所以先做成这个样子了。

如果要让PHP代码操作浏览器的DOM,必须写PHP扩展,使用Emscripten的API去调用JavaScript,这还是可以做的。

而JavaScript很多接口都是需要回调的,Emscripten也是可以做到,但是只是回调到C/C++,如果要回调到PHP,就要自己实现协程方案,这我还做不了。

目前可以完善和尝试的:

  1. 语法检查
  2. 错误信息显示
  3. 减少代码体积
  4. 处理内存泄漏

如果你有什么有趣的想法,也不妨提个issue或者评论一下。

2018.10.20:

  1. PHP升级到7.3 RC2
  2. Ace编辑器提供基本的语法检查
  3. 通过LLVM LTO性能提高了1倍,文件缩小到3.9M(gzip后1.1M)
  4. 内存泄漏再次出现(曾经的变通方案无效了)
本作品采用《CC 协议》,转载必须注明作者和本文链接
Oraoto
《L04 微信小程序从零到发布》
从小程序个人账户申请开始,带你一步步进行开发一个微信小程序,直到提交微信控制台上线发布。
《G01 Go 实战入门》
从零开始带你一步步开发一个 Go 博客项目,让你在最短的时间内学会使用 Go 进行编码。项目结构很大程度上参考了 Laravel。
讨论数量: 15

体验很差,打开页面后 Google Chrome Helper 进程 %CPU直接飙升200.. 然后忍了十秒还在加载中。不知道是不是我打开方式有问题。科学上网和正常网络都试过了,一样的结果。

5年前 评论
Oraoto

@skyjerry 目前是这样的 :joy: 因为加载wasm之后浏览器还要进行编译,CPU就会爆高,Chrome尤其明显,Firefox和Edge加载会快很多。

5年前 评论

好像还是有问题,不知道是不是我本地的问题,我这次用的Firefox,编译完CPU降下去了,然后..就没有然后了,一直加载中

5年前 评论
Oraoto

@skyjerry 这就尴尬了§:з)))」∠) Firefox版本是?我只试过FF 61,不嫌麻烦的话,可以看看控制台的输出。

5年前 评论
Oraoto

@skyjerry 加载中是浏览器在转圈,还是红色按钮还是显示Loading?如果按钮显示Run了就可以了。

5年前 评论

@Oraoto 浏览器转圈,不知道原因

5年前 评论

这个功能不错哦

5年前 评论
wkan

运行 exit(1) 然后就凉了

5年前 评论
Oraoto

@wkan 的确,刚刚修复了:) exit(1)示例,还是有输出缓冲和内存问题。

5年前 评论

有意思的项目 👍

5年前 评论

把php拿到前台编译运行的, 正常的流程应该是, 先编译成wasm, 然后js fetch, 直接用, 这个太慢了

5年前 评论
Oraoto

@mafa1993 文章中也提到类似的方案,难度更大,还没完整地支持PHP语法。现在加载和运行的确慢,正考虑精简不需要的函数来减小体积。

5年前 评论

:+1: 好创意 支持

2年前 评论

讨论应以学习和精进为目的。请勿发布不友善或者负能量的内容,与人为善,比聪明更重要!