|
My routines often involve my habits good and bad.
For instance, my routine of taking a break after every phone call, code victory, code stump, or just anxiety involves getting up and walking. Unfortunately, it's usually walking to the workshop/smoking den where I indulge my habit.
Edward Aymami wrote: How does either one affect the work that you do?
Given that this routine uses timers, I can estimate that distractions cost an additional 15 minutes each of productivity, or around 2 hours per day on average!
"Go forth into the source" - Neal Morse
"Hope is contagious"
|
|
|
|
|
Habits are optional and perhaps enjoyable; routines are chores.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
I'm in the habit of never doing the same twice: when I hear the word "routine," I call an exorcist.
Β«The mind is not a vessel to be filled but a fire to be kindledΒ» Plutarch
|
|
|
|
|
Both. The best way for me is when habits - which are usually based on some reasoning behind - become routine as it lower the probability of mistakes (think of driving safety, trigger discipline, electric safety, fire hazards).
Routine becomes habit just because our brain will naturally follow the order of operations and muscle memory is a pretty big thing.
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
I'd put it
Habit: action most always done after something else, regardless if needs doing or not
going out of house, keys wallet and phone, even if knowingly wont need wallet, just habit to take
routine: something you do regardless of anything before or after.
wallet in back left pocket, phone in front left, keys front right, regardless if have the others, they will be in these assigned places.
|
|
|
|
|
I look at it differently (typical of a Navy Nuc with ADHD - we ainβt quite right in the head π).
I find a rhythm that works, that gets me at my most productive in a way that helps me get the most satisfaction out of my work. That becomes the routine I strive for each day. It is a macro approach to what I do.
In the specific implementations of what I do, I find patterns that not only help me do my work better now, but over the long term. That is my micro approach to what I do, which are my habits.
For me, the two are rarely related directly. But they do provide me with better productivity, better quality, a better way to improve my SDLC, and get more enjoyment from my work.
When the unplanned for things of daily life occur, I adapt my routine (and occasionally my habits) and overcome whatever obstacles they provide.
|
|
|
|
|
Wordle 463 3/6
π©π©π¨β¬β¬
π©π©π©π©β¬
π©π©π©π©π©
|
|
|
|
|
Wordle 463 2/6
π©β¬π¨π©π©
π©π©π©π©π©
|
|
|
|
|
Wordle 463 5/6
β¬β¬π¨π¨β¬
β¬β¬π¨π¨β¬
π¨β¬π¨β¬β¬
π©β¬π¨π©β¬
π©π©π©π©π©
|
|
|
|
|
Wordle 463 3/6
π©β¬β¬β¬β¬
π©β¬β¬β¬π©
π©π©π©π©π©
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
β¬β¬π¨β¬β¬
π©β¬β¬β¬π©
π©π©π©π©π©
Life should not be a journey to the grave with the intention of arriving safely in a pretty and well-preserved body, but rather to skid in broadside in a cloud of smoke, thoroughly used up, totally worn out, and loudly proclaiming βWow! What a Ride!" - Hunter S Thompson - RIP
|
|
|
|
|
Wordle 463 3/6
β¬β¬π¨β¬β¬
π©β¬π¨π©β¬
π©π©π©π©π©
|
|
|
|
|
Wordle 463 3/6
β¬β¬β¬β¬π©
β¬π¨β¬π©π©
π©π©π©π©π©
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
I already don't like writing caches.
I especially don't like writing "generalized" containers without templates.
And yet here I am, needing a glyph cache to bring my font rendering from 6fps closer to 23fps (my target baseline)
And debating about whether it's worth it to generalize it in order to save flash space if someone else needs a similar facility in LVGL.
The hashtable part is relatively easy. The least recently accessed expiration mechanism is less so.
I just don't like writing caches. It combines everything I don't like about writing containers with even more complexity that's easy to get wrong. And it all has to perform or it defeats its own purpose. Meh.
To err is human. Fortune favors the monsters.
|
|
|
|
|
Then I can recommend this movie: CachΓ©.
modified 11-Nov-22 12:24pm.
|
|
|
|
|
A couple of simple least recently accessed mechanisms that I can think of are
- A global integer that increments on every access and is written against the item accessed. When space is needed, free the item(s) with the lowest access values. Low overhead for accesses but could be expensive when freeing space, especially if there are a fair number of items or space often needs to be freed. Also needs to handle the access counter wrapping around.
- A two-way queue. When an item is accessed, exqueue it and put it at the front of the queue. When space is needed, free the item(s) at the end of the queue. More expensive for accesses but faster at freeing space.
I've got a sense that I don't understand your constraints, because you've probably ruled these approaches out for some reason.
|
|
|
|
|
I'm doing the first one, basically. Except instead of a global it's a cache specific incrementer.
I was trying to remove some of the crawls by keeping track of the last age I freed but it didn't work.
Also I ran into some other issues. It's just annoying not being able to abstract this stuff the way I'd like to.
To err is human. Fortune favors the monsters.
|
|
|
|
|
When the dance is over the piper must be paid. Only two forms of currency are accepted:
- CPU cycles
- Memory (cache aligned)
Loans and credit are not available!
|
|
|
|
|
It was fun, when I could search the memory for a value; say the 366 gold I start with in Pirates! and just change it. The amount of men once I attack Panama? Well, just enough to die after we raid Cartegena to divide up the plunder!
It is C#, just more verbose at times.
Bastard Programmer from Hell
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
honey the codewitch wrote: And it all has to perform or it defeats its own purpose.
That's the challenge.
Personally, I treat C as a high-level assembly language. I use it in almost all places that I would have used assembly language 40 years ago, the exceptions being hardware addressing and code that requires extremely high, processor-dependent, levels of optimization.
I am aware that some embedded C compilers have extensions that allow hardware addressing, but there is a tendency by some programmers to use those everywhere, rather than just in a hardware interface module. This makes porting the software difficult to impossible. If portability is an issue, forcing programmers to write portable C with a few non-portable assembly language modules works better, IMO.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
For this I don't need to drop to assembly or anything fancy. In fact, the generation time for these cached items is such that the cache itself could perform pretty badly and still provide substantial performance improvements.
When I wrote that I was more speaking in terms of principle, *except* when it comes to expiring items. That's the one area where it really concerns me because I have to crawl the entire cache.
To err is human. Fortune favors the monsters.
|
|
|
|
|
You have two problems here, which should ideally be solved using two mechanisms. Note that an object's handle won't work as an LRU timestamp because it is fixed, and an LRU timestamp won't work as an object's handle because it is subject to change.
The LRU cache maintenance can most easily be performed using a doubly-linked list. This is only one more word per cache node than is used for your timestamp method, is easy to implement, and is extremely fast.
Searching the cache is a separate problem. A red-black tree sorted by the objects' handles would solve this problem nicely.
If memory constraints prevent you from implementing both LRU and search mechanisms, you will have to fall back to a linear search for one of the operations.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
my issue with the linked list is heap frag, and I'm wondering whether or not a red-black tree would be better than a hashtable given i don't need to keep things in sorted order.
What I've been doing (although I ran into issues and probably have to try again) is creating a hashtable. I just needed an integer key, and each entry has an age. The age *increases* when you retrieve something. When it needs to make more room it expires items with the smallest age.
To err is human. Fortune favors the monsters.
|
|
|
|
|
honey the codewitch wrote: I just needed an integer key The memory address is already unique. Can't imagine why you'd need to generate another unique key.
|
|
|
|
|
Because I need to be able to look it up later.
Specifically, I'm caching glyph bitmaps I render from a vector font. They cache needs to be keyed to the ID of the glyph.
To err is human. Fortune favors the monsters.
|
|
|
|