#premature optimization

[kawaoneechan]

Today's Project Special K ponderings

Size of the Villager class: 1472 bytes.

Amount of villagers currently in the set: 55, including ACNH cats.

Amount of villagers planned: 110.

Projected total size of the villager dataset in memory: 161,920 bytes or 158 KiB.

Size of an std::string: 40 bytes, assuming MSVC 2015.

Size of a CRC32 hash: 4 bytes, obviously.

Therefore, you could decimate the part of a villager where it specifies the item ID for their default outfit, their raincoat, rain hat, umbrella, photograph, and portrait, from 240 to only 24.

But this doesn't work because those items can and do have variants specified — Audie's tropical muumuu is specifically mint, and "acnh:tropicalmuumuu" does not have the same hash as "achnh:tropicalmuumuu/mint", obviously.

So that idea is no good.

Size of a TextureArray*: 8 bytes. This is a 64-bit application.

Size of an std::array<TextureArray*, 24>: 192 bytes.

With 24 textures for the character and another 32 for their clothing (gotta support the lowest common denominator and that means more than just tops and accessories), that makes 448 bytes per villager for their textures, even if they're not physically present and no textures are loaded.

Projected total size of these texture pointers: 49,280 bytes or 48 KiB, not counting the actual textures.

I could replace these std::array<>s with a single pointer. When the villager is spawned in, 56 TextureArray* are allocated and used, and freed along with their contents when the villager is despawned.

But is that really worth it for 448 bytes?

House data is left unloaded. It's in the JSON file, but nothing actually loads it into the Villager class, which has no fields for it.

But villagers, like all NameableThings, remember which JSON file they were loaded from.

Therefore, when the topic of home decorations comes up, the relevant data can be pulled out on the spot.

This is for later, we don't even have map transitions yet.

Parsing a reference like "acnh:tropicalmuumuu/mint" involves a couple string creations and destructions.

I'd use std::string_view but I'm stuck with C++11.

I also don't get to use std::format for the same reason, but I do get to use fmt::format to fill that gap quite nicely. Likewise, I could probably dig up some library to give me string views.

But parsing these references isn't exactly something that happens every frame, or every few seconds.

So is it worth the effort to find a string view "polyfill" and use it? Are there other places in the code where using a view would be a boon? Finding file entries in the VFS certainly goes fast when running a release build...

[usunezukoinezu]

''Unfortunately, people often make the mistake of doing way too much work before testing assumptions in the real world. In computer science this trap is called premature optimization, where you tweak or perfect code or algorithms (optimize) too early (prematurely). If your assumptions turn out to be wrong, you’re going to have to throw out all that work, rendering it ultimately a waste of time.

It’s as if you booked an entire vacation assuming your family could join you, only to finally ask them and they say they can’t come. Then you have to go back and change everything, but all this work could have been avoided by a simple communication up front.''

-Gabriel Weinberg and Lauren McCann, Super Thinking

[nolifer-pl]

Engineering Architecture - Jakub Kubryński

[nostalgichistorian]

Working Theory: Premature optimization is not a sin of greed, but rather a sin of pride.

[macaroniio]

Quitting iPhone apps as a habit

I've noticed more and more people around me habitually quitting iOS apps on their iPhones. They  will quit every single app until there is nothing left in the task switcher.

As far as I'm aware, this is rather unnecessary but maybe there are some reasons that people have that I'm not aware of. Is it trying to clean everything up? Is it to combat performance issues?

If you know anything about this then get in touch and let me know. Hopefully we can improve lives together.

[gsharm1]

Great piece by Jason Fried, of 37signals:

There’s no question that automation is enticing – especially for software companies. No one disputes it’s easier to scale your business when you have machines doing the work.

But automation can also lead to myopia. And premature-automation can lead to blindness. When you take human interaction out of a system, you’re removing key opportunities to see what really happens along the way. You miss stories, experiences, and struggles – and that’s often where the real insights are hiding.

[workstuff]

In praise of appropriate simplicity

Recently on a mailing list, an inexperienced programmer asked for help with constructing a set of relational tables to store a list of users with a category.

I suggested keeping it simple, with a single relational field and only two tables:

CREATE TABLE categories (   id int(11) NOT NULL AUTO_INCREMENT,   name varchar(100) DEFAULT '',   PRIMARY KEY (`id`)   ) ENGINE=InnoDB DEFAULT CHARSET=utf8;   CREATE TABLE users (   id int(11) NOT NULL AUTO_INCREMENT,   first_name varchar(100) DEFAULT '',   last_name varchar(100) DEFAULT '',   category_id int(11),   PRIMARY KEY (`id`),   CONSTRAINT `user_category_ibfk_1` FOREIGN KEY (`category_id`) REFERENCES `categories` (`id`)   ) ENGINE=InnoDB DEFAULT CHARSET=utf8;

With this table structure, you can do:

mysql> insert into categories (name) values ("one");   Query OK, 1 row affected (0.00 sec)   mysql> insert into categories (name) values ("two");   Query OK, 1 row affected (0.00 sec)   mysql> insert into categories (name) values ("three");   Query OK, 1 row affected (0.00 sec)   mysql> insert into users (first_name, last_name, category_id) values ('joe', 'blogs', 1);   Query OK, 1 row affected (0.00 sec)   mysql> insert into users (first_name, last_name, category_id) values ('harry', 'potts', 2);   Query OK, 1 row affected (0.00 sec)   mysql> insert into users (first_name, last_name, category_id) values ('miner', 'niner', 2);   Query OK, 1 row affected (0.00 sec)   mysql> insert into users (first_name, last_name, category_id) values ('jeebus', 'saves', 3);   Query OK, 1 row affected (0.01 sec)   mysql> SELECT * from users order by last_name desc;   +----+------------+-----------+-------------+   | id | first_name | last_name | category_id |   +----+------------+-----------+-------------+   | 4 | jeebus | saves | 3 |   | 2 | harry | potts | 2 |   | 3 | miner | niner | 2 |   | 1 | joe | blogs | 1 |   +----+------------+-----------+-------------+   4 rows in set (0.00 sec)   mysql> SELECT u.*, c.name from users u left join categories c on u.category_id = c.id order by last_name desc;   +----+------------+-----------+-------------+-------+   | id | first_name | last_name | category_id | name |   +----+------------+-----------+-------------+-------+   | 4 | jeebus | saves | 3 | three |   | 2 | harry | potts | 2 | two |   | 3 | miner | niner | 2 | two |   | 1 | joe | blogs | 1 | one |   +----+------------+-----------+-------------+-------+   4 rows in set (0.00 sec)

Some people immediately commented that I was wrong in not telling her to plan for the future requirements and start with the user/category relationships as a separate mapping table. And often, I'd agree with that, but in this particular case, I think that's a premature optimization that puts a lot more work up front, especially since she wasn't even comfortable enough to figure out how to code the simpler relationship herself without help. There are gotchas when dealing with n:n relationship data (layout and prepopulation issues with the multiple select box, figuring out how to properly update relationships in the list, etc...), and it helps to have gotten to that point yourself. Using a mapping table and limiting it with a unique index on the mapping table will push off some of the UI issues, but I pointed out that making the db change later is the least difficult part of this migration, and it can be done with two sql statements that don't affect any existing data:

  mysql> create table user_categories (   -> id int auto_increment primary key,   -> category_id int,   -> user_id int   -> );   Query OK, 0 rows affected (0.12 sec)   mysql> insert into user_categories (category_id, user_id) (select category_id, id from users);   Query OK, 5 rows affected (0.03 sec)   Records: 5 Duplicates: 0 Warnings: 0  

At the point at which you need to do this, it's a trivial change shrouded in the other more complicated things you'll be doing at the same time to support real n:n relations, and the code you need to use to interact with it in the meantime can be simpler. And, of course, if the requirement to have more than one category per user never materializes, you've saved yourself some work upfront.

Sometimes planning for the future is a good idea, and you should always keep it in mind, but that doesn't mean it's always the right way to design your data structures. Sometimes the value of the simpler shortsighted case outweighs its potential drawbacks.