Create accountLogin

Recent searches

No recent searches

Search options

Only available when logged in.
en.osm.town is one of the many independent Mastodon servers you can use to participate in the fediverse.
An independent, community of OpenStreetMap people on the Fediverse/Mastodon. Funding graciously provided by the OpenStreetMap Foundation.

Administered by:

Server stats:

268
active users

en.osm.town: AboutProfiles directoryPrivacy policy

Mastodon: AboutGet the appKeyboard shortcutsView source codev4.3.7

#performance

7 posts7 participants0 posts today
Public *
Aptivi

Linux 6.15’s exFAT file deletion performance boosted

A recent development in the upcoming Linux 6.15 kernel has been spotted, because there was a big improvement to the exFAT file system implementation in relation to how it deletes the files when the “discard” mount option is used. This improvement significantly saves time as a test file after the merge has been deleted in 1.6 seconds, compared to more than 4 minutes of the total time taken.

This pull request makes sure that, upon file deletion, it discards a group of contiguous clusters (that is, clusters that are next to each other) in batch instead of discarding them one by one. This was because in prior kernels, such as 6.14, “if the discard mount option is enabled, the file’s clusters are discarded when they are freed. Discarding clusters one by one will significantly reduce performance. Poor performance may cause soft lockup when lots of clusters are freed.”

The change has been introduced in commit a36e0ab. Since then, the pull request has been merged to the kernel and it will be integrated to the first release candidate of Linux 6.15. A simple performance benchmark has been verified with the following commands:

# truncate -s 80G /mnt/file# time rm /mnt/file

In detail, the performance of this filesystem without this commit is poor, totalling about 4 minutes and 46 seconds in real time, with 12 seconds of system time. In contrast to the patched kernel, it totals about 1 second in real time, with 17 milliseconds of system time.

It’s a huge improvement!

Image by diana.grytsku on Freepik

#Computers#exFAT#Filesystem
Public *
Jeff Fortin T.

Pro tip to spot performance issues that manifest as CPU hogs on the #Linux desktop: configure GNOME System Monitor (or any resources monitor applet like the "Astra monitor" GNOME Shell extension) to *not* be in "Solaris mode", i.e. to NOT "divide CPU usage by CPU count".

That way, you get bigger numbers that are easily noticed, and when you see "12%" on a 8-vCores system, you instantly know that the process you're looking at is pegging 100% of one virtual CPU core.

#profiling#performance
Public *
OpenHistoricalMap

Despite all the mega boundary mapping lately, our map just got a lot leaner and faster. Map tiles have shrunk by as much as 96% compared to last year! #MicDrop

Also in this month’s update, some nice tweaks and additions to the main style and a proper sendoff to @run_for_funner:

forum.openhistoricalmap.org/t/

OpenHistoricalMap Forum · Better performance, less clutter, and the end of an eraGood write-up @Minh_Nguyen !! I’d like to add a few statistics about tile sizes and PostGIS query performance. Overall, the optimization went well — it significantly reduced both the size and rendering time of the tiles, especially for the most expensive layer: land_ohm_lines. 📏 Vector Tile Size Statistics 🔗 View Tile Stats – San José Metric 🔴 Before Optimization 🟢 After Optimization Improvement Total tiles 18 9 📦 Fewer tiles due to ...
#performance#VectorTiles#OpenHistoricalMap
Public
Jeff Fortin T.

I'd want Nautilus (and thus the #GNOME file picker UI) to stop trying to search multiple times per second while I am not nearly done typing the search query, as I consider that to be extremely wasteful, conceptually. Pounding the CPU+GPU "faster than I can think & type" is counterproductive.
If you don't "feel the jank" like I do, then think about the wasted energy (especially on battery power):
gitlab.gnome.org/GNOME/nautilu

GitLabSlow searching with micro-hangs when typing quickly with many search results (#3452) · Issues · GNOME / Files · GitLabTLDR: although it has improved in 44-46, and with the fix for
#performance#EnergyEfficiency#PowerManagement
Continued thread
Public
Fedify: an ActivityPub server framework

Coming soon in #Fedify 1.5.0: Smart fan-out for efficient activity delivery!

After getting feedback about our queue design, we're excited to introduce a significant improvement for accounts with large follower counts.

As we discussed in our previous post, Fedify currently creates separate queue messages for each recipient. While this approach offers excellent reliability and individual retry capabilities, it causes performance issues when sending activities to thousands of followers.

Our solution? A new two-stage “fan-out” approach:

  1. When you call Context.sendActivity(), we'll now enqueue just one consolidated message containing your activity payload and recipient list
  2. A background worker then processes this message and re-enqueues individual delivery tasks

The benefits are substantial:

  • Context.sendActivity() returns almost instantly, even for massive follower counts
  • Memory usage is dramatically reduced by avoiding payload duplication
  • UI responsiveness improves since web requests complete quickly
  • The same reliability for individual deliveries is maintained

For developers with specific needs, we're adding a fanout option with three settings:

  • "auto" (default): Uses fanout for large recipient lists, direct delivery for small ones
  • "skip": Bypasses fanout when you need different payload per recipient
  • "force": Always uses fanout even with few recipients
// Example with custom fanout setting
await ctx.sendActivity(
  { identifier: "alice" },
  recipients,
  activity,
  { fanout: "skip" }  // Directly enqueues individual messages
);

This change represents months of performance testing and should make Fedify work beautifully even for extremely popular accounts!

For more details, check out our docs.

What other #performance optimizations would you like to see in future Fedify releases?

Flowchart comparing Fedify's current approach versus the new fan-out approach for activity delivery. The current approach shows: 1. sendActivity calls create separate messages for each recipient (marked as a response time bottleneck) 2. These individual messages are queued in outbox 3. Messages are processed independently 4. Three delivery outcomes: Recipient 1 (fast delivery), Recipient 2 (fast delivery), and Recipient 3 (slow server) The fan-out approach shows: 1. sendActivity creates a single message with multiple recipients 2. This single message is queued in fan-out queue (marked as providing quick response) 3. A background worker processes the fan-out message 4. The worker re-enqueues individual messages in outbox 5. These are then processed independently 6. Three delivery outcomes: Recipient 1 (fast delivery), Recipient 2 (fast delivery), and Recipient 3 (slow server) The diagram highlights how the fan-out approach moves the heavy processing out of the response path, providing faster API response times while maintaining the same delivery characteristics.
#ActivityPub#fedidev
ExploreLive feeds
About