Compiler: See compiler output

Go to https://godbolt.org/ and enter the following C++ code:

#include <stdio.h>
class MyClass {
  public:
    void* prop0;
    int prop1;
    void test() { prop1++; }
    MyClass() {
        prop0 = NULL;
        prop1 = 0;
    }
};
void meuk() {
    MyClass c;
    c.test();
    int i = 100;
}

https://www.geeksforgeeks.org/peephole-optimization-in-compiler-design

https://www.geeksforgeeks.org/loop-optimization-in-compiler-design

https://www.geeksforgeeks.org/symbol-table-compiler

Postgresql: Number of sql statements per second

Check if the pg_stat_statements extension is active in Postgresql:

select * from pg_extension;

If not, then:
  execute in SQL:   create extension pg_stat_statements;
  in Postgresql.conf modify:  shared_preload_libraries = 'pg_stat_statements'

Restart server, and now you can see the sql statements per second:

-- queries per second
with
 t1 as (select sum(calls) n from pg_stat_statements),
 t2 as (select sum(calls) n from pg_stat_statements , pg_sleep(1))
select
 t2.n-t1.n the_num_of_queries_per_second
from
 t1,t2;
 
-- Top time consuming queries
select userid::regrole, dbid, query ,calls, 
(total_plan_time + total_exec_time) / 1000 as total_time_seconds, 
(min_plan_time + min_exec_time) / 1000 as min_time_seconds, 
(max_plan_time + max_exec_time) / 1000 as max_time_seconds, 
(mean_plan_time + mean_exec_time) / 1000 as mean_time_seconds
from pg_stat_statements
order by (mean_plan_time + mean_exec_time) desc
limit 10;
   
-- queries having high i/o activity
select userid::regrole, dbid, query,queryid,
   (mean_plan_time + mean_exec_time)/1000 as mean_time_seconds 
from pg_stat_statements
order by (blk_read_time+blk_write_time) desc
limit 10;

-- queries with high memory usage
select userid::regrole, dbid, queryid,query  from pg_stat_statements 
order by (shared_blks_hit+shared_blks_dirtied) desc
limit 10;

-- reset the stats
select pg_stat_statements_reset();

-- number of queries running at this moment
select * from pg_stat_activity;

-- number of queries running for more than 30 seconds
select * from pg_stat_activity
where (now() - query_start) > interval '30 seconds';

-- What is the replication server?
select * from pg_stat_replication;

-- The Usertables having a tablescan:
select relname, seq_scan from pg_stat_user_tables order by seq_scan desc;

-- Put the tablescan values in a separate tmp table for comparison at a later time
create table stats_snapshot_0938 as select relname, seq_scan from pg_stat_user_tables;
-- select * from stats_snapshot_0938;
-- drop table stats_snapshot_0938;

-- Compare the values with the old values...
select stats_now.relname, (stats_now.seq_scan - stats_old.seq_scan) difference
from pg_stat_user_tables stats_now
join stats_snapshot_0938 stats_old on stats_now.relname = stats_old.relname
order by difference desc;

C64: using $D000-$DFFF for a custom font

A good location for a custom C64 font is at location $D000-$DFFF.

> But wait! Are the VIC-II registers not mapped at $D000?

Yes, that is right, but it can be switched with the character ROM by clearing bit 2 on location $0001.

> But wait! Then you have character ROM at that location. How can you set a custom font?

When the font ROM is switched into area $D000-$DFFF and the CPU stores bytes at these locations between $D000-$DFFF, they will not be stored into the ROM but to the underlying RAM. So the CPU reads from ROM and writes to RAM in that situation.

When the I/O is activated into area $D000-$DFFF, the VIC-II registers are used in this area and the CPU will read and write to the VIC-II registers.

So, it is only possible to store values into the RAM area $D000-$DFFF when the font ROM is switched in. The CPU can never read a value from this RAM area. So what is the use? Well, the VIC-II will see the RAM, so you can put a custom charset at this location, or other VIC-II data. 

When the font ROM is switched into area $D000-$DFFF, only the CPU will see the ROM, not the VIC-II. The only locations where the VIC-II chip will see the character ROM is at the locations $1000-$1FFF and $9000-$9FFF. These are the so-called Shadow Font area's. Let this sink in, before you get confused.

We can conclude that the locations $1000-$1FFF and $9000-$9FFF are highly suitable for code, because the VIC-II will only see the character ROM at these locations and the CPU will only see the RAM.

The $D000-$DFFF RAM area can only contain VIC-II data, because the bytes cannot be loaded by the CPU. This makes this area suitable for a custom font. If the I/O is activated in this area, the CPU will return the VIC-II register values and if the character ROM is activated in this area, the CPU will return the character ROM bytes. So, you can only store values in this RAM area when the ROM is switched in, the CPU can never read values from this RAM. A custom font is static in most cases, so suitable for this area. However if you want 'rotating' characters, this area is not suitable.

C64: Test kernal version

?peek(65408)

-> 170 = kernal version 1   (poke 1024,81 results in a white ball)
-> 0 = kernal version 2   (poke 1024,81 results in a blue ball which cannot be seen)
-> 3 = kernal version 3 (poke 1024, 81 results in a light-blue ball which is visible on screen)

Kernal version 3 is the one everyone uses. 

vlang: see the generated C output

To see the generated C output of the vlang compiler:
v -o - test.v > test.c

Clean NPM cache

 npm cache clean --force