Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

100M-Row Challenge with PHP

github.com

Post reply on HN
Print view View original

21–30 of 104 posts

Re: 100M-Row Challenge with PHP

#21

Post by monkey_monkey »

Tade0 wrote: post #11
brentroose wrote: post #2

A month ago, I went on a performance quest trying to optimize a PHP script that took 5 days to run. Together with the help of many talented developers, I eventually got it to run in under 30 seconds. This optimization process with so much fun, and so many people pitched in with their ideas; so I eventually decided I wanted to do something more. That's why I built a performance challenge for the PHP community The goal…

Pitch this to whoever is in charge of performance at Wordpress. A Wordpress instance will happily take over 20 seconds to fully load if you disable cache.

That's often a skill issue.

Re: 100M-Row Challenge with PHP

#22

Post by olmo23 »

kpcyrd wrote: post #20
brentroose wrote: post #8

Earlier quoted context omitted.

The FAQ states that solutions like FFI are not allowed because the goal is to solve it with PHP :)

What about using the filesystem as an optimized dict implementation?

this is never going to be faster because it requires syscalls

Re: 100M-Row Challenge with PHP

#23

Post by Xeoncross »

This is why I jumped from PHP to Go, then why I jumped from Go to Rust.

Go is the most battery-included language I've ever used. Instant compile times means I can run tests bound to ctrl/cmd+s every time I save the file. It's more performant (way less memory, similar CPU time) than C# or Java (and certainly all the scripting languages) and contains a massive stdlib for anything you could want to do. It's what scripting languages should have been. Anyone can read it just like Python.

Rust takes the last 20% I couldn't get in a GC language and removes it. Sure, it's syntax doesn't make sense to an outsider and you end up with 3rd party packages for a lot of things, but can't beat it's performance and safety. Removes a whole lot of tests as those situations just aren't possible.

If Rust scares you use Go. If Go scares you use Rust.

Re: 100M-Row Challenge with PHP

#24

Post by poizan42 »

> The output should be encoded as a pretty JSON string.

...

> Your parser should store the following output in $outputPath as a JSON file:

    {
        "\/blog\/11-million-rows-in-seconds": {
            "2025-01-24": 1,
            "2026-01-24": 2
        },
        "\/blog\/php-enums": {
            "2024-01-24": 1
        }
    }
They don't define what exactly "pretty" means, but superflous escapes are not very pretty in my opinion.

Re: 100M-Row Challenge with PHP

#25

Post by codegeek »

Xeoncross wrote: post #23

This is why I jumped from PHP to Go, then why I jumped from Go to Rust. Go is the most battery-included language I've ever used. Instant compile times means I can run tests bound to ctrl/cmd+s every time I save the file. It's more performant (way less memory, similar CPU time) than C# or Java (and certainly all the scripting languages) and contains a massive stdlib for anything you could want to do. It's what scripti…

I am not that smart to use Rust so take it with a grain of salt. However, its syntax just makes me go crazy. Go/Golang on the other hand is a breath of fresh air. I think unless you really need that additional 20% improvement that Rust provides, Go should be the default for most projects between the 2.

Re: 100M-Row Challenge with PHP

#26

Post by semiquaver »

Are they just confused about what characters require escaping in JSON strings or is PHP weirder than I remember?

    {
        "\/blog\/11-million-rows-in-seconds": {
            "2025-01-24": 1,
            "2026-01-24": 2
        },
        "\/blog\/php-enums": {
            "2024-01-24": 1
        }
    }

Re: 100M-Row Challenge with PHP

#27

Post by poizan42 »

semiquaver wrote: post #26

Are they just confused about what characters require escaping in JSON strings or is PHP weirder than I remember? { "\/blog\/11-million-rows-in-seconds": { "2025-01-24": 1, "2026-01-24": 2 }, "\/blog\/php-enums": { "2024-01-24": 1 } }

> The output should be encoded as a pretty JSON string.

So apparently that is what they consider "pretty JSON". I really don't want to see what they would consider "ugly JSON".

(I think the term they may have been looking for is "pretty-printed JSON" which implies something about the formatting rather than being a completely subjective term)

Re: 100M-Row Challenge with PHP

#28

Post by kijin »

poizan42 wrote: post #24

> The output should be encoded as a pretty JSON string. ... > Your parser should store the following output in $outputPath as a JSON file: { "\/blog\/11-million-rows-in-seconds": { "2025-01-24": 1, "2026-01-24": 2 }, "\/blog\/php-enums": { "2024-01-24": 1 } } They don't define what exactly "pretty" means, but superflous escapes are not very pretty in my opinion.

They probably mean "Should look like the output of json_encode($data, JSON_PRETTY_PRINT)". Which most PHP devs would be familiar with.

Re: 100M-Row Challenge with PHP

#29

Post by _yvnd »

semiquaver wrote: post #26

Are they just confused about what characters require escaping in JSON strings or is PHP weirder than I remember? { "\/blog\/11-million-rows-in-seconds": { "2025-01-24": 1, "2026-01-24": 2 }, "\/blog\/php-enums": { "2024-01-24": 1 } }

That's the default output when using json_encode with the JSON_PRETTY_PRINT flag in php.

Re: 100M-Row Challenge with PHP

#30

Post by poizan42 »

kijin wrote: post #28
poizan42 wrote: post #24

> The output should be encoded as a pretty JSON string. ... > Your parser should store the following output in $outputPath as a JSON file: { "\/blog\/11-million-rows-in-seconds": { "2025-01-24": 1, "2026-01-24": 2 }, "\/blog\/php-enums": { "2024-01-24": 1 } } They don't define what exactly "pretty" means, but superflous escapes are not very pretty in my opinion.

They probably mean "Should look like the output of json_encode($data, JSON_PRETTY_PRINT)". Which most PHP devs would be familiar with.

It sounds plausible, but they really need to spell out exactly what the formatting requirements are, because it can make a huge difference in how efficiently you can write the json out.
Post reply on HN