Programming – Page 2 – Andy Balaam's Blog

One import per line is best

Rust has a feature where if you import two things from the same module you can abbreviate it like this:

use mypkg::{MyStruct1, MyStruct2};

If you prefer, you can keep them separate, like this:

use mypkg::MyStruct1;
use mypkg::MyStruct2;

I do prefer. Strongly.

Advantages of the abbreviated style

Fewer lines of code
Fewer characters of code

Advantages of the separated style

Simpler diffs with fewer conflicts. If I add or delete an import, it adds or removes exactly one line. This makes it easier to read diffs and reduces conflicts when merging.
Less diff noise when lines overflow. Adding or removing an import is less likely to cause the code formatter to reflow the line. Reflows make it hard to see which dependencies have changed when reading a diff.
Easier searching. If I’m trying to find out where a particular type is used I can search for its full path, and my search will find all the places I import it.

Easier to read. I find line of code like this really hard to read:

use crate::{
    gossiping::{GossipRequest, GossippedSecret, SecretInfo},
    identities::{ReadOnlyDevice, ReadOnlyUserIdentities},
    olm::{OutboundGroupSession, PrivateCrossSigningIdentity},
    types::events::room_key_withheld::RoomKeyWithheldEvent,
    TrackedUser,
};

I think the separated style is much better, and I wish Rustfmt defaulted to using it. What do you think?

rustfmt config

To enforce my preferred style, include this in your rustfmt.toml:

imports_granularity = Item

(Rustfmt docs)

Rust 101 – 15: Lifetime bounds

This time we tackle one of the most tricky areas for a new Rust programmer: lifetimes. The key point is that when we add lifetime bounds ('a or similar) to a function signature, this is not to help Rust compile our function: it’s to help Rust understand the lifetime of our return values, so that it knows how to compile the code that calls this function. The lifetime bounds tell the compiler about the references we return – specifically, how they relate to the references that were passed in.

Series: 1: Intro, 2: Language basics, 3: Memory and ownership, 4: Exercises A1, 5: References, 6: Structs and Enums, 7: Panic and Result, 8: Methods, 9: Vec and Box, 10: Strings, 11: Exercises A2, 12: Traits, 13: Type Params, 14: std Traits, 15: Lifetimes, 16: Exercises A3pt1, 17: Exercises A3pt2, 18: Dependencies, 19: API design, 20: Tests

Links:

Slides: Rust 101 – 15: Lifetime bounds
Exercises: 101-rs.tweede.golf/A3-traits-generics/mod.html

The course materials for this series are developed by tweede golf. You can find more information at github.com/tweedegolf/101-rs and you can sponsor the work at github.com/sponsors/tweedegolf. They are released under the Creative Commons Attribution Share Alike 4.0 International license.

Rust 101 – 14: Some standard library traits

A tour of some of the most interesting traits in the standard library including Add etc. to overload operators, Sized, Sync and Send for telling the compiler special things about your type, Clone and Copy for copying things, Into and From for converting, AsRef and AsMut for making your APIs flexible, Default for easy creation, and Drop which is called when your object is deleted. Also a few words on what happens when you call a function with generic type parameters.

Links:

Slides: Rust 101 – 14: Some standard library traits
Exercises: 101-rs.tweede.golf/A3-traits-generics/mod.html

Rust 101 – 13: Type Parameters and Associated Types

Following on from video 12, looking at how to add type information to traits, to make them flexible enough to describe generic code with different types, for example how to add a u32 to a u64 and return a u128, without defining a whole new trait for every combination of types.

Links:

Slides: Rust 101 – 13: Type Parameters and Associated Types
Exercises: 101-rs.tweede.golf/A3-traits-generics/mod.html

Deleting an Indexed DB store can be incredibly slow on Firefox

We had performance problem in Element Web when upgrading the Indexed DB schema, and it turned out that in Firefox, deleting an object store can be incredibly slow. It can take tens of minutes or even hours.

(In Chromium the same operation can take tens of seconds, but it’s way, way faster.)

I was expecting this to be a near-instant operation, so this was a definite surprise to me.

Note that my analysis is based on widely-available browsers in February 2024, and will probably become out-of-date.

You can see the full graphs here: artificialworlds.net/indexed-db-perf/delete.html. Source code is at codeberg.org/andybalaam/indexed-db-perf.

Here’s what I learned:

Headline 1: Firefox can take a very long time to delete an object store

Graph showing that Firefox took 1.2 million milliseconds to delete an object store containing 200K records.

Firefox took 20 minutes to delete an object store containing 200K records, with one index.

In Chromium, I found that deleting a similar object store took 21 seconds, which is still slow, but rather more acceptable.

Consider not deleting stores you don’t need any more. If you must delete them, you will need to provide feedback to your users, especially if they are using Firefox.

Headline 2: Clearing the store before deleting it really helps(!)

Graph showing that Firefox takes 1.2 million ms to delete a large object store (200K records), or 300 thousand ms if you clear it before deleting it.

Graph showing that Chromium takes 20 thousand ms to delete a large object store (200K records), or 10 thousand ms if you clear it before deleting it.

On both Firefox and Chromium, running objectStore.clear() before upgrading the db and deleting the store made a significant improvement to the total time. On Chromium it more than halved the time to delete the store, and on Firefox (where the numbers were huge) it reduced the time by about 3 times!

Thanks to michael-p on Stack Overflow for giving me the idea.

Clear your store before deleting it.

Headline 3: With no indices, this is fine

Firefox deletes object stores fairly fast if there are no indices (and so does Chromium).

Graph showing that even for 200K records, Firefox can delete an object store in under 500ms if there is no index on it.

Even for 200K records, Firefox can delete an object store in under 500ms if there is no index on it.

If you need fast deletion, don’t use indices.

Observation: It’s not done until the DB is closed

In my timing experiments, I found that objectStore.delete() completed, but the operation was not really done. When I called the close() method on my IDBDatabase I had to wait a whole lot longer. (The close time is included in the measurements above.)

Even when I refreshed the browser, I found I had a long wait to open the Indexed DB database. After the wait, it worked fine and the schema update was complete.

Expect long close times after a deletion.