Newest at the top
| 2024-04-24 15:03:57 +0200 | ystael | (~ystael@user/ystael) |
| 2024-04-24 14:57:32 +0200 | <ph88> | how can i denote that something is of kind type ? |
| 2024-04-24 14:52:07 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Quit: = "") |
| 2024-04-24 14:34:58 +0200 | Inst | (~Inst@user/Inst) (Ping timeout: 246 seconds) |
| 2024-04-24 14:32:22 +0200 | koz | (~koz@121.99.240.58) |
| 2024-04-24 14:30:35 +0200 | koz | (~koz@121.99.240.58) (Ping timeout: 260 seconds) |
| 2024-04-24 14:19:52 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-04-24 14:18:25 +0200 | danse-nr3 | (~danse-nr3@151.19.252.50) |
| 2024-04-24 14:18:16 +0200 | rvalue | (~rvalue@user/rvalue) |
| 2024-04-24 14:13:46 +0200 | rosco | (~rosco@yp-146-6.tm.net.my) (Quit: Lost terminal) |
| 2024-04-24 14:10:35 +0200 | akegalj | (~akegalj@78-1-52-121.adsl.net.t-com.hr) |
| 2024-04-24 14:10:12 +0200 | rvalue | (~rvalue@user/rvalue) (Ping timeout: 268 seconds) |
| 2024-04-24 14:07:42 +0200 | <ph88> | code loaded in RAM/cache but not executed is not going to make a significant difference in the benchmark results with so many iterations |
| 2024-04-24 14:06:51 +0200 | p3n | (~p3n@2a00:19a0:3:7c:0:d9c6:7cf6:1) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2024-04-24 14:05:53 +0200 | <ph88> | You can click on the buttons below "Test types" https://www.techempower.com/benchmarks/ it was already like that when the haskell frameworks where still on the charts |
| 2024-04-24 14:05:15 +0200 | <ph88> | It's an end to end test for 5 different uses cases in 1 codebase for each implementation. The implementations are then compared to each other |
| 2024-04-24 14:05:10 +0200 | <dminuoso> | It introduces the notion that modular frameworks cant exist. |
| 2024-04-24 14:04:58 +0200 | <dminuoso> | That's a silly requirement, then. |
| 2024-04-24 14:04:21 +0200 | <dminuoso> | You can do JSON and database interaction with *different* libraries and get different results. |
| 2024-04-24 14:04:13 +0200 | <ph88> | it's part of the benchmark requirements so that all implementations have some kind of database handler inside. That doesn't mean that that code gets executed for all benchmarks |
| 2024-04-24 14:04:05 +0200 | <dminuoso> | Because snap has neither JSON nor database interaction. |
| 2024-04-24 14:03:58 +0200 | <dminuoso> | And there should also not be a JSON handler |
| 2024-04-24 14:03:42 +0200 | <dminuoso> | That's what Im saying. |
| 2024-04-24 14:03:40 +0200 | <dminuoso> | ph88: There should not be a db handler to begin with! |
| 2024-04-24 14:03:29 +0200 | <ph88> | the mysql handler should not be hit on the route that serves plaintext |
| 2024-04-24 14:03:23 +0200 | <dminuoso> | Just using what you imagine would probably be used is a silly thing to do. |
| 2024-04-24 14:02:59 +0200 | <dminuoso> | You're suddenly conflating snap with mysql-simple |
| 2024-04-24 14:02:41 +0200 | <dminuoso> | ph88: Dunno, so if you look at snap, there shouldnt even be a database handler in there because snap does not have database interaction. |
| 2024-04-24 14:01:40 +0200 | <ph88> | but ecosystem optimization is best measured by libraries commonly used shared between many real world apps |
| 2024-04-24 14:01:21 +0200 | <Inst> | considering its baseline was garbage, of course :3 |
| 2024-04-24 14:01:14 +0200 | <dminuoso> | Especially for libraries. |
| 2024-04-24 14:01:06 +0200 | <dminuoso> | ph88: Performance is best measured in your specific problem domain, because chances are the bottlenecks will things you dont think about. |
| 2024-04-24 14:00:28 +0200 | <Inst> | IHP is doing much better these days |
| 2024-04-24 14:00:22 +0200 | <ph88> | ye that's of course up to you if you want to crunch millions of tree nodes in a blocking way |
| 2024-04-24 14:00:19 +0200 | <dminuoso> | ph88: Ah fiar enough. |
| 2024-04-24 13:59:51 +0200 | <dminuoso> | Routing overhead? Probably microseconds? |
| 2024-04-24 13:59:40 +0200 | <dminuoso> | The HTTP overhead? Completely negligable. |
| 2024-04-24 13:59:40 +0200 | <ph88> | it's one codebase for about 5 different benchmarks, it's been this way for many years |
| 2024-04-24 13:59:31 +0200 | <dminuoso> | In my HTTP code, about half the time is spend in database IO, and the other is spend in crunching on millions of tree nodes. |
| 2024-04-24 13:59:28 +0200 | rvalue | (~rvalue@user/rvalue) |
| 2024-04-24 13:59:07 +0200 | <Inst> | https://www.techempower.com/benchmarks/#section=data-r22&hw=ph&test=json |
| 2024-04-24 13:58:57 +0200 | <ph88> | if you want to add in additional parts there are also benchmarks with json formatting and postgresql access |
| 2024-04-24 13:58:42 +0200 | <ph88> | all parts combined are relevant and http and routing is part of the total latency |
| 2024-04-24 13:58:36 +0200 | <dminuoso> | With mysql-simple. |
| 2024-04-24 13:58:34 +0200 | <dminuoso> | ph88: The snap code does more, it also does database interaction |
| 2024-04-24 13:58:16 +0200 | <dminuoso> | If http and routing performance is ever relevant to you, you will either have reached global scaling or have a very exotic use case. |
| 2024-04-24 13:58:04 +0200 | <ph88> | somebody put up that snap benchmark code as best effort at the time |
| 2024-04-24 13:57:37 +0200 | <ph88> | on real world code you add in more libraries and IO, if we want to compare the webserver part only plaintext is the best benchmark to test routing and simple responses |
| 2024-04-24 13:56:49 +0200 | <dminuoso> | And it mixes in a bunch of libraries to the point that its impossible to say why this is slow. |
| 2024-04-24 13:56:27 +0200 | zwrv | (~yin@user/zero) |