3 ms·

I for one will not be running this sort of low performance setup when PhpWM would obviously be an order of magnitude faster. *it really would though

HeckFeck 3y ago
> *it really would though I imagine the vast optimisations that came in PHP7, likely at Meta and Wordpress's behest, would be to thank for that.
- wharvle 3y ago
  Eh, it’s been fast in the real world for quite a while. I think it’s due to two main things: 1) Startup time had to be fast because of how it worked in its most common use case (yes, yes, FPM, but still) which tends to encourage or require making everything fast. 2) Writing C modules for PHP is relatively easy and it has a culture of anything halfway important being in C, going back to the early days of the language. The answer for how to be really fast with real-world workloads in almost every scripting language is basically “get out of it and into C ASAP” but PHP’s culture embraces that more than most.
exikyut 3y ago
Rock: PHP X11 PoC that I poked at a couple years ago (which doesn't use libx11/libxcb, but talks directly to /tmp/.X11-unix/X0) Hard place: crowd of Wayland pitchforks thundering in the distance Effort analysis: <negative beeping> Itch: scratch? Me: annoyed twitching
- vidarh 3y ago
  As you can see if you dig into my code and then look at the X protocol implementation [1], the (incomplete) pure Ruby X11 binding takes up more lines of code than the WM. I was tempted to write the code to generate it from the XML spec, but a lot of the scaffolding for the current X11 binding predated my own work and it seemed like it'd be more and more painful work to write the generator than bite the bullet and do it manually (I don't expect to/care about supporting the whole protocol anyway). So a PHP version would be totally viable, just tedious. [1] https://github.com/vidarh/ruby-x11 https://github.com/vidarh/ruby-x11
  - tonyg 3y ago
    If you do ever return to the idea of generating the X11 protocol code, you might find https://github.com/tonyg/xcb-shim https://github.com/tonyg/xcb-shim interesting. I wrote it to simplify X11 implementation generally. I've used it just once, so far, though, to build a Squeak Smalltalk native X11 protocol implementation.
    - vidarh 3y ago
      That's really useful, thank you. I have been considering massaging the Ruby version into a different structure as while the current one is fairly nice in some respects (such as providing support for both parsing and generating both "sides" of the protocol, entertaining my delusion of possible writing an X server), it also could definitely be faster and smaller...
      - tonyg 3y ago
        Do get in touch if you do pick this up again, I'd be interested in collaborating or at least keeping track of how it goes; it was a bit lonely figuring out how to do X for Squeak in a vacuum :-)
vidarh 3y ago
I know this is a joke, but, this goes right back to the first time I deployed Ruby and had "the speed discussion" with people. We deployed a Ruby queueing server that used 10x as much CPU in the Ruby code than our preceding C version spent in its code (that wording is careful). It was also 1/10th the LOC and had more features, and given we spent ca 1/10th of a 2006-era Xeon core in user space, it felt like a worthwhile sacrifice - the vast majority of time was spent in the kernel handling IO. It was what made me fall in love with Ruby: There are so many spaces where the time is spent elsewhere and the time spent doing things slowly in Ruby (though much faster than it used to be) doesn't matter. Like a window manager. I've even made performance tradeoffs that makes it much slower: On every adjustment of the layout, I iterate over every single window the WM knows about to filter a list of the wm's on this desktop, that are visible, and compare that to a serialized list of every single window that exists in the layout tree. Because it's fast enough, and it saves bothering to keep proper track of state, and makes some of the code simpler. Knowing when you can afford to pick the slow options on purpose is powerful. Knowing when you can't afford to, is also important.

HeckFeck 3y ago

> *it really would though I imagine the vast optimisations that came in PHP7, likely at Meta and Wordpress's behest, would be to thank for that.

wharvle 3y ago
Eh, it’s been fast in the real world for quite a while. I think it’s due to two main things: 1) Startup time had to be fast because of how it worked in its most common use case (yes, yes, FPM, but still) which tends to encourage or require making everything fast. 2) Writing C modules for PHP is relatively easy and it has a culture of anything halfway important being in C, going back to the early days of the language. The answer for how to be really fast with real-world workloads in almost every scripting language is basically “get out of it and into C ASAP” but PHP’s culture embraces that more than most.

exikyut 3y ago

Rock: PHP X11 PoC that I poked at a couple years ago (which doesn't use libx11/libxcb, but talks directly to /tmp/.X11-unix/X0) Hard place: crowd of Wayland pitchforks thundering in the distance Effort analysis: <negative beeping> Itch: scratch? Me: annoyed twitching

vidarh 3y ago
As you can see if you dig into my code and then look at the X protocol implementation [1], the (incomplete) pure Ruby X11 binding takes up more lines of code than the WM. I was tempted to write the code to generate it from the XML spec, but a lot of the scaffolding for the current X11 binding predated my own work and it seemed like it'd be more and more painful work to write the generator than bite the bullet and do it manually (I don't expect to/care about supporting the whole protocol anyway). So a PHP version would be totally viable, just tedious. [1] https://github.com/vidarh/ruby-x11 https://github.com/vidarh/ruby-x11
- tonyg 3y ago
  If you do ever return to the idea of generating the X11 protocol code, you might find https://github.com/tonyg/xcb-shim https://github.com/tonyg/xcb-shim interesting. I wrote it to simplify X11 implementation generally. I've used it just once, so far, though, to build a Squeak Smalltalk native X11 protocol implementation.
  - vidarh 3y ago
    That's really useful, thank you. I have been considering massaging the Ruby version into a different structure as while the current one is fairly nice in some respects (such as providing support for both parsing and generating both "sides" of the protocol, entertaining my delusion of possible writing an X server), it also could definitely be faster and smaller...
    - tonyg 3y ago
      Do get in touch if you do pick this up again, I'd be interested in collaborating or at least keeping track of how it goes; it was a bit lonely figuring out how to do X for Squeak in a vacuum :-)

vidarh 3y ago

I know this is a joke, but, this goes right back to the first time I deployed Ruby and had "the speed discussion" with people. We deployed a Ruby queueing server that used 10x as much CPU in the Ruby code than our preceding C version spent in its code (that wording is careful). It was also 1/10th the LOC and had more features, and given we spent ca 1/10th of a 2006-era Xeon core in user space, it felt like a worthwhile sacrifice - the vast majority of time was spent in the kernel handling IO. It was what made me fall in love with Ruby: There are so many spaces where the time is spent elsewhere and the time spent doing things slowly in Ruby (though much faster than it used to be) doesn't matter. Like a window manager. I've even made performance tradeoffs that makes it much slower: On every adjustment of the layout, I iterate over every single window the WM knows about to filter a list of the wm's on this desktop, that are visible, and compare that to a serialized list of every single window that exists in the layout tree. Because it's fast enough, and it saves bothering to keep proper track of state, and makes some of the code simpler. Knowing when you can afford to pick the slow options on purpose is powerful. Knowing when you can't afford to, is also important.