The goal of the article is not to know the exact numbers by heart, duh!
Care about orders of magnitude instead, in combination with the speed of hardware https://gist.github.com/jboner/2841832 you'll have a good understanding of how much overhead is due to the language and the constructs to favor for speed improvements.
Just reading the code should give you a sense of its speed and where it will spend most time.
Combined with general timing metrics you can also have a sense of the overhead of 3rd party libraries (pydantic I'm looking at you).
So yeah, I find that list quite useful during the code design, likely reduce time profiling slow code in prod.
In that time the java app parsed 50 strings for object hierarchies (using a regex that isn't cached) and extracted values from a request object to a processing object, handled errors, and logged results.
3 times.
This is the naive version of that code, because "I will parallelize it later" and I was just getting the logic down.
Turns out, when you use programming languages that are fit for purpose, you don't have to obsess over every function call, because computers are fast.
I think people vastly underestimate how slow python is.
We are rebuilding an internal service in Java, going from python, and our half assed first attempts are over ten times faster, no engineering required, exactly because python takes forever just to call a function. The python version was dead, and would never get any faster without radical rebuilds and massive changes anyway.
It takes python 19ns to add two integers. Your CPU does it in about 0.3 ns..... in 2004.
That those ints take 28 bytes each to hold in memory is probably why the new Java version of the service takes 1/10th the memory as well.
22ns might be about 100 processor instructions. Somehow I doubt that any programming language can parse 50 strings in 100 instructions, let alone with naive code.
Python is slow but in my experience (that mostly relates to web services and data processing) I found that I/O was by far the biggest bottleneck. Waiting for the database, another http service or local storage, which often takes more than 1ms anyway.
Well you nailed it, the language you're looking for is SQL.
There's a reason why duckdb got such traction over the last years.
I think data scientists overlook SQL and Excel like tooling.
But on the other hand, that's doesn't mean SQL is ideal - far from it. When using DuckDB with Python, to make things more succinct, reusable and maintainable, I often fall into the pattern of writing Python functions that generate SQL strings.
But that hints at the drawbacks of SQL: it's mostly not composable as a language (compared to general purpose languages with first-class abstractions). DuckDB syntax does improve on this a little, but I think it's mostly fundamental to SQL. All I'm saying is that it feels like something better is possible.
About the cookie banners, I'm honestly not sure it's a regulation issue.
For >90% of the websites the "reject all" option have no impact on user experience, so either everybody is breaching or the banner is useless in the first place.
Do you get prompted for the choice the next time you visit the website? Are they websites you need to log in to? Those are really the only user experience things that would be obvious in most instances — everything else is just pure data mining for usage analytics (::knowing wink::) and overt tracking. Some sites absolutely do not respect any of the choices, but that’s not the normal behavior.
With that it becomes clear that some service is self hosted (the DNS record points to a private IP).
It can be a security issue when the Whois record or the domain name allows the identification of the hosting entity. Finding its physical address can be an easy task depending on its social presence.
Then probably the hosting place is an easier target than a data center.
To be fair nowadays .com refer much more to the default, main or official domain of an entity. Say you know the name of a non corporate website, are going to try .com first of something else?
Diffusely is an AI media enhancement company that leverages its cutting-edge media processing platform to develop tailored products for specific verticals: Carcutter for the automotive industry, Autoretouch for the fashion one and Propershot in real estate.
As a Backend Engineer at CarCutter, you will be joining the global #1 visual AI editing and optimization solution for the automotive industry, used by customers from all around the world. Due to our steady growth, we are now expanding our passionate & motivated CarCutter team.
reply