Apple Migrates Its Password Monitoring Service to Swift from Java, Gains 40% Performance Uplift (infoq.com) 54
Meta and AWS have used Rust, and Netflix uses Go,reports the programming news site InfoQ. But using another language, Apple recently "migrated its global Password Monitoring service from Java to Swift, achieving a 40% increase in throughput, and significantly reducing memory usage."
This freed up nearly 50% of their previously allocated Kubernetes capacity, according to the article, and even "improved startup time, and simplified concurrency." In a recent post, Apple engineers detailed how the rewrite helped the service scale to billions of requests per day while improving responsiveness and maintainability... "Swift allowed us to write smaller, less verbose, and more expressive codebases (close to 85% reduction in lines of code) that are highly readable while prioritizing safety and efficiency."
Apple's Password Monitoring service, part of the broader Password app's ecosystem, is responsible for securely checking whether a user's saved credentials have appeared in known data breaches, without revealing any private information to Apple. It handles billions of requests daily, performing cryptographic comparisons using privacy-preserving protocols. This workload demands high computational throughput, tight latency bounds, and elastic scaling across regions... Apple's previous Java implementation struggled to meet the service's growing performance and scalability needs. Garbage collection caused unpredictable pause times under load, degrading latency consistency. Startup overhead — from JVM initialization, class loading, and just-in-time compilation, slowed the system's ability to scale in real time. Additionally, the service's memory footprint, often reaching tens of gigabytes per instance, reduced infrastructure efficiency and raised operational costs.
Originally developed as a client-side language for Apple platforms, Swift has since expanded into server-side use cases.... Swift's deterministic memory management, based on reference counting rather than garbage collection (GC), eliminated latency spikes caused by GC pauses. This consistency proved critical for a low-latency system at scale. After tuning, Apple reported sub-millisecond 99.9th percentile latencies and a dramatic drop in memory usage: Swift instances consumed hundreds of megabytes, compared to tens of gigabytes with Java.
"While this isn't a sign that Java and similar languages are in decline," concludes InfoQ's article, "there is growing evidence that at the uppermost end of performance requirements, some are finding that general-purpose runtimes no longer suffice."
This freed up nearly 50% of their previously allocated Kubernetes capacity, according to the article, and even "improved startup time, and simplified concurrency." In a recent post, Apple engineers detailed how the rewrite helped the service scale to billions of requests per day while improving responsiveness and maintainability... "Swift allowed us to write smaller, less verbose, and more expressive codebases (close to 85% reduction in lines of code) that are highly readable while prioritizing safety and efficiency."
Apple's Password Monitoring service, part of the broader Password app's ecosystem, is responsible for securely checking whether a user's saved credentials have appeared in known data breaches, without revealing any private information to Apple. It handles billions of requests daily, performing cryptographic comparisons using privacy-preserving protocols. This workload demands high computational throughput, tight latency bounds, and elastic scaling across regions... Apple's previous Java implementation struggled to meet the service's growing performance and scalability needs. Garbage collection caused unpredictable pause times under load, degrading latency consistency. Startup overhead — from JVM initialization, class loading, and just-in-time compilation, slowed the system's ability to scale in real time. Additionally, the service's memory footprint, often reaching tens of gigabytes per instance, reduced infrastructure efficiency and raised operational costs.
Originally developed as a client-side language for Apple platforms, Swift has since expanded into server-side use cases.... Swift's deterministic memory management, based on reference counting rather than garbage collection (GC), eliminated latency spikes caused by GC pauses. This consistency proved critical for a low-latency system at scale. After tuning, Apple reported sub-millisecond 99.9th percentile latencies and a dramatic drop in memory usage: Swift instances consumed hundreds of megabytes, compared to tens of gigabytes with Java.
"While this isn't a sign that Java and similar languages are in decline," concludes InfoQ's article, "there is growing evidence that at the uppermost end of performance requirements, some are finding that general-purpose runtimes no longer suffice."
Uh oh (Score:2)
Now angle of sphere is going to go on a German fueled rant about how memory consumption doesn't matter because Java is awesome and totally isn't needlessly verbose.
Re: (Score:2)
Basically like this:
https://youtu.be/oy2VqDi4sFg?t... [youtu.be]
Re: (Score:2)
I was half-expecting this:
https://www.youtube.com/watch?... [youtube.com]
Re: Uh oh (Score:1)
Re: (Score:1)
Everything is illegal in Germany.
Re: (Score:2)
I wonder if Apple started the migration after the change in Oracle's licensing model in January 2023?
The Java SE Universal Subscription was introduced in January 2023 to an outcry from licensing experts and analysts. It moved licensing of Java from a per-user basis to a per-employee basis. At the time, Oracle said it was "a simple, low-cost monthly subscription that includes Java SE Licensing and Support for use on Desktops, Servers or Cloud deployments." However, licensing advisors said early calculations to help some clients showed that the revamp might increase costs by up to ten times. Later, analysis from Gartner found the per-employee subscription model to be two to five times more expensive than the legacy model. https://developers.slashdot.or... [slashdot.org]
It's not the language. It's tech debt. (Score:5, Insightful)
Whenever you rewrite a product in a new stack you pretty much create it from scratch. You do things right and don't bring all the patchwork and tech debt with you. That's what caused this speed-up. No the change of the language.
Re:It's not the language. It's tech debt. (Score:4, Interesting)
More than likely, but Java does have a lot of inherent problems that almost certainly didn't help. It's also quite plausible that garbage collection was biting them pretty hard; example: https://discord.com/blog/why-d... [discord.com]. The whole reason for switching in that case was because of GC, which is inherent to the language's runtime, and you can't do anything about it. And of course: Java IS a memory hog. Java DOES take a long time to spin up, both initially and for new threads.
They probably would have done slightly better with rust given you can simply rely on normal pointers instead of reference counting, but knowing Apple that probably came down to an NIH decision.
Give the statistics of the java vs swift code (Score:2)
- number of classes
- Number of classes which inherit from another class
- Number of external API endpoints
- Number of internal API endpoints
- Number of calls to external systems, databases, services, storage, etc.
- Number of methods
- Breakdown of methods into deciles by lines of code per method (actual lines of code, comments, white space removed)
- Number of try catch blocks in the code
- Number of throw exceptions in the code
- Number of lambda calls in the code
- Number of namespaces
- Average number of identi
object - wire format - object (Score:2)
A guess would be that they did multiple repeated object -> wire format (text, json, http body) -> object format for each call.
Re: (Score:2)
Garbage collection is faster than reference counting, not slower. Reference counting has the benefits of being deterministic and avoiding pauses, but it has more overhead overall. If you're concerned about throughput, garbage collection wins.
I'd take this story with a grain of salt. Apple claims the language they invented and promote is better than others. What a surprise! It sounds more like propaganda than a real technical analysis.
Re: (Score:2)
ARC, as you mention, is deterministic and avoids non-deterministic pauses.
In the case where a particular run may not run any mark-and-sweep, it will perform better, depending on what really needs to be done for destruction, but only just barely- however, cross some transparent threshold, and instantly watch your throughput be far less. Modern multi-generational collectors exist precisely because of this problem.
This is easily demonstrable in benchmarks.
Of course, since we'r
Re: (Score:2)
One of the things to note here is that this is a mature, well defined, and simple microservice and one with little actual data concurrency.
So for this, Java IS overkill and the challenges of tuning GC are going to be real. So i'm not surprised that other languages did better. Go, Rust, C or C++ would also have been good choices.
The peak and trough of a day differ by approximately 50% regionally. To efficiently manage this, we aim to scale down when demand is low and scale up as demand peaks in different regions. A faster bootstrap time is a crucial requirement to support this dynamic scaling strategy.
One thing of note though is that java app startup times for an app that size are still going to be say ~1 min. and that's going to be cut to what ? 10 sec? This is not reall
If you think Java has problems.... (Score:3)
More than likely, but Java does have a lot of inherent problems that almost certainly didn't help. It's also quite plausible that garbage collection was biting them pretty hard; example: https://discord.com/blog/why-d... [discord.com]. The whole reason for switching in that case was because of GC, which is inherent to the language's runtime, and you can't do anything about it. And of course: Java IS a memory hog. Java DOES take a long time to spin up, both initially and for new threads.
They probably would have done slightly better with rust given you can simply rely on normal pointers instead of reference counting, but knowing Apple that probably came down to an NIH decision.
...try their competitors!!!
If you're comparing to Rust?...OK, fair...if you're comparing to Go...oh, that's a painfully slow and disappointing garbage platform...the difficulty of C with the performance of node/Python. Node.js and Python are famously slow and bloated...and C# just really doesn't compete, even before you consider the MS factor.
We are in a new interesting era where platformless choices are becoming an option, like Rust. Go was interesting...until you see the performance...since Java i
Re: (Score:2)
dude, i'm relatively a fan of server side java, but where is this coming from?
Go...oh, that's a painfully slow and disappointing garbage platform...the difficulty of C with the performance of node/Python.
i've only played with Go a little, but from what i read i thought was generally quite good. Like faster than or on par with Java for CPU and network usecases.
Re: (Score:2)
I've worked with Go a bit. It's definitely easier than C in that you've got a garbage collector to help you avoid segfaults (and unlike Java, you're not forced to pass everything but primitive types by reference) and you don't have to drop your function signatures into every file you're calling them from.
But Go has a few drawbacks that really ruin the language for me: No enums. Period. This really sucks for somebody like me who makes heavy use of Rust's excellent enums (really, IMO rust's killer feature IS
Re: (Score:2)
Node.js and Python are famously slow and bloated...and C# just really doesn't compete, even before you consider the MS factor.
Golang will perform way better than those (and who the FUCK thought making a server side language out of js was a good idea?) But actually if somebody held a gun to my head and said pick C# or Java for your next project, I'd take C#. Java honestly feels like an early alpha release of C#. C# is heavily inspired by Java, but also eliminated most of its crap. Like for example, checking if two strings are equal ACTUALLY CHECKS IF THEY'RE EQUAL, not merely the same fucking class instance. C# has CLI tooling that
Re: (Score:3)
You do things right and don't bring all the patchwork and tech debt with you.
You also fail to bring certain subtle business requirements with you, that have organically developed over time, while also reintroducing many bugs that were fixed years ago.
Re: (Score:2)
*cough* Vista *cough*
Re: It's not the language. It's tech debt. (Score:2)
Sometimes it's for the better. ;-)
Re: (Score:2)
Rewriting usually only works on small projects. Projects where tech debt can't really accumulate because they're relatively small and self contained and making modifications is relatively trivial.
Larger projects accumulate tech debt because it's large, unwieldy to the point where mak
Re: (Score:2)
Here, the problem looks like it was relatively self-contained and small, and likely had very little tech debt to begin with being likely something can easily have refactored.
This exactly. it's a relatively simple microservice with a small and stateless API and well defined behavior. It's a dream candidate for this kind of experimentation.
Their original app was probably garbage (Score:2)
Whenever you rewrite a product in a new stack you pretty much create it from scratch. You do things right and don't bring all the patchwork and tech debt with you. That's what caused this speed-up. No the change of the language.
Agreed! In addition, Apple has a BAD history when it comes to software. They have the "reverse-midas-touch" when it comes to software...in that anything they touch turns to shit....look at iTunes as a shining example. They've gotten better in the last decade, but I will wager their legacy app was garbage...probably some old struts app from the early aughts...maybe some EJB 2.1 magic?
What I am interested in, when evaluating platforms, is how much of a performance benefit Swift will provide vs a well-w
Re: (Score:2)
most likely, they do actually hint at architectural changes in the otherwise uninformative but boasting abstract. except we'll never really know because they won't show any code to compare.
dunno, i'm an old nerd and somehow still do have a soft spot for /. but ... who actually reads this sort of retarded advertising crapware nowadays?
Re: (Score:2)
Swift in general tends to outperform Java by 20% or so.
Obviously some of it is a superior refactor. Some of it is the fact that Java is shit.
say what? (Score:3)
"...close to 85% reduction in lines of code..."
Extremely unlikely. Worse yet, anyone who would claim this is clearly not a programmer.
Re: (Score:1)
If you've ever worked on a legacy codebase then you know it grows organically and a lot of new additions can be nearly duplicates of existing code, just tweaked for different scenarios. And sometimes dead code isn't removed. This isn't a fault of the language, but of the new people working on the system that haven't gotten properly familiar with what's already there, and reviewers not calling out submissions for these problems because they're under the gun to just "approve, approve, approve."
In other words
Re: (Score:2)
Bullshit. An 85% reduction would be 20 lines of code reduced to 3 lines. There is no explanation for such a reduction, and dead code isn't code.
Re: (Score:3)
Depending on how old the Java code was it could have had:
A lot of boiler plate interface / factory / etc patterns.
Collection modifiers run as for loops instead of single line functions like apply / map / etc.
Much more concise when it comes to import statements.
Swift has named parameters, so maybe the Java code used a parameter object as arguments for readability.
Swift lets you write extensions for pre-existing classes which can neaten up a lot of code (granted you can do this in Java with some interesting a
Re: say what? (Score:4, Insightful)
dead code isn't code.
That is the necrophilia motto. "Dead body is not a body. No crime."
Re: (Score:2)
I do not know Swift, but I have worked professionally in 11 programming languages and studied a few others. Some languages are just more efficient at expressing either specific topics or general notation. Java tends to be verbose. As an example: Quicksort in Java is ~30 lines of code. Quicksort in Haskell is 5 lines for similar time complexity. It's not beyond imagination that Swift, as a more modern language where advanced features let you express whole chunks of code in one keyword, could be really effici
Re: (Score:2)
In Java style taught in schools, they'd have an explosion of tiny classes that do not do a lot of work. Then you have a whole group of design patterns that only exist because of having to put everything into OOP. Such as the Singleton pattern or the flyweight pattern which exist to circumvent the rigid paradigm of Java.
If you define protocols and a lot of language overhead that adds up to a lot of compiler bound code that produces next to nothing in the end but hints to the compiler.
I could see a rewrite ge
Re: (Score:3)
I'd say this is plausible, but mainly because Java has a lot of ceremonious cruft that most languages don't even need. I've never used swift, but if it doesn't force you to bundle everything into a namespace and a class like Java does, then it already has a big advantage in terms of being concise, and most of all, using fewer lines. That would be especially true if they followed a lot of Java'isms like creating getters and setters for everything, which in most cases is really just an excuse to add a lot of
Re: (Score:2)
a language may have cruft but that doesn't mean code written in that language does, and things like namespaces don't account for 17 out of every 20 lines of code. Yes, different languages could have different line counts, but not differences so great.
Re: (Score:2)
In an extremely heavy allocate/free environment, GC in Java will take something like 10 minutes out of every hour. Which is significant, but you shouldn't see a 40% increase in throughput from that either.
Someone else suggested they were probably parsing JSON/XML repeatedly or something similar, which is possible considering 'parsing' is just a simple function c
Not News (Score:5, Insightful)
Apple reports that the language Apple wrote performs well when a bunch of Apple engineers use it to remake a project. Why is this news?
There are hundreds, if not *thousands* of devs on Slashdot who have rewritten something ... even in the same language ... and seen massive performance improvements. The fact that a 2.0 version of something has the potential to be better than the 1.0 is not news, and neither is anything else in this article.
It doesn't even offer a real comparison of Java vs. Swift, because they didn't just translate Java => Swift ... they wrote an entirely new version of the code, so it's impossible to tell what parts of the performance increase came from the language change, and what came from the rewrite.
Where's the AI? (Score:3)
I fell down the stairs and hurt myself. AI has made me all better. Thank you, AI!
Java (Score:2)
Java vs it's competitors (Score:2)
While I know Java doesn't inherently have to be slow and use excessive resources, I've never seen a significantly complex Java application that utilizes resources as expected. The CPU and memory usage is always a factor of 10X what I'd expect from a C++ application. I don't know the reasons as I'm not a Java developer, but I also don't find Java enticing enough to learn enough to find out.
Java is quite fast and reasonable in memory usage. It is far superior to it's normal competitors, Go (the slowest disappointment I've ever used), Python, JavaScript, and C#. While C# and Go are better languages than Python & JavaScript, IMHO, Java is the king of those 5 when it comes to response time performance.
Now if you're comparing well-written Java to well-written C++...C++ should have a strong and noticeable advantage. Rust is noticeably faster and lighter as well.
Java's strength is speed
Re: (Score:2)
Of languages that suck, Java doesn't really suck! For languages that do not use resources well, Java does not use resources poorly!
Garbage collected languages do not use memory well. Applications that avoid dynamic memory use can mitigate that shortcoming.
Re: Java vs it's competitors (Score:1)
I tend to view Java as a holdover people locked into what their doing, a bit like Cobol.
These same people try to force Java into lambda architectures and claim the performance problems are not their fault.
Re: (Score:2)
Re: (Score:2)
Java is quite fast and reasonable in memory usage. It is far superior to it's normal competitors
and C#.
lolwut? [vercel.app]
and Go
lolwut? [vercel.app]
Seriously, what fucking universe are you in where Java is competitive?
Now Python- lol- I'll give you that, but Python and Java aren't really comparable. Python is an interpreted language, Java is not.
Ironically (Score:2)
Java usually gives me swift performance gains, especially early in the morning. :-)
Re: (Score:2)
If I have too much it gives me the shits.
Same as it ever was (Score:1)
This has always been the case. Since the late 50's there were languages designed to run fast and others that were programmer-friendly instead of machine-friendly.
Performance (Score:2)
has never been one of Java's strong suits.