After the mysql library is used, the memory is high

[tgy3300]

use mysql::{
    prelude::Queryable,
    OptsBuilder, Pool, PooledConn, Row,
};

#[tokio::main]
async fn main() {
    let cli = get_client(&TidbConfig {
        host: "127.0.0.1".to_string(),
        user: "root".to_string(),
        pwd: "123456".to_string(),
        db_name: "shop".to_string(),
        port: 3306,
    });
    App::new(cli).run().await
}

struct App {
    client: PooledConn,
}
impl App {
    fn new(client: PooledConn) -> Self {
        Self { client }
    }
    async fn run(&mut self) {
        let res: Option<Row> = self.client.query_first("select * from company").unwrap();
        println!("-----{:#?}", res);

        tokio::select! {
            _ = tokio::signal::ctrl_c() => {},
        }
    }
}

fn get_client(c: &TidbConfig) -> PooledConn {
    let opts = OptsBuilder::new()
        .ip_or_hostname(Some(&c.host))
        .user(Some(&c.user))
        .pass(Some(&c.pwd))
        .db_name(Some(&c.db_name))
        .tcp_port(c.port);
    let pool = Pool::new(opts).unwrap();
    let conn = pool.get_conn().unwrap();
    conn
}

struct TidbConfig {
    host: String,
    user: String,
    pwd: String,
    db_name: String,
    port: u16,
}

Through the cargo build -r mission package out of the package, after starting, why the memory is so high, after debugging, is the reason for mysql library, I have any problems with the use of mysql library?

[ZiCog]

What actually is the problem here? You have VS Code using over three gigabytes of memory but highlight a process using only 40MB ? Which is nothing by comparison.

[tgy3300]

VSCode's features are so complete compared to VSCode, is it comparable? Is it normal for my rust code to take up so much memory on a single query? The same function, I write in golang, about the point of 5M or so of memory.

It is said that rust's performance is compared with c++, if the performance of such a small code is not as good as golang, how can it be compared with c++, so I wonder if I used it wrong

[paramagnetic]

Measuring memory alocation is hard, and it's not as simple as "calling free(ptr) or drop(resource) gives back the memory to the OS". Modern memory allocators try to hold on already-allocated memory and cache as much of it as possible, to avoid having to issue expensive system calls upon every single allocation.

And even when releasing resources does actually release memory to the OS, it may still not be reported as "free" and it may not even show up in any metric.

Basically, the only thing you can be sure about is: if your program runs without touching swap space, then you had enough memory, otherwise you didn't. Anything else (e.g. quite frankly bullshit metrics shown by the task manager) is a lie and not to be taken seriously the least bit.

@tgy3300

It is said that rust's performance is compared with c++, if the performance of such a small code is not as good as golang, how can it be compared with c++, so I wonder if I used it wrong

Your program is so small and trivial that it's not even worth benchmarking. Differences in e.g. the size of dynamically-allocated and "leaked" standard I/O buffers (which depends on the language runtime) can suggest a disproportionately large difference between such tiny programs that it's basically down in the noise.

Go write a large production service in Go and Rust and measure the difference using a real profiler (not Task Manager). Then you'll learn something useful. But not with a 50-line trivial program.

[erelde]

There are a few things here that probably makes your program use more memory than what you'd expect. First is the flavor of tokio runtime you're using, then the connector library you're using seems to setup a pool of db connectors by default. Probably other things, but I'm on my phone and I'm just giving hints for you to investigate.

[jonnyso]

At first I also thought it could be a pool, but wouldnt that apear as the mysql process instead of his program ?

[jofas]

The pool is a bunch of reusable TCP or Unix domain socket (or the Windows version of UDS) connections inside your program. The pool does not spin up mysql child processes or calls out to some mysql client process but handles the connections completely in the main process.

[tgy3300]

You say that the indicators of the task manager have no reference value, but I think this is also a kind of performance, I hope that the official or the big guys give more advice

[bjorn3]

Any memory allocator with remotely decent performance will not immediately release freed memory back to the OS. Instead they will keep it around for a while in case it is needed in the future. Only after a certain amount of time or if the OS itself signals that there is too little free memory, do memory allocators release memory back to the OS and thus reduce the memory usage shown in task manager. You need to use a memory profiler to get the actual amount of memory the program consumes. The difference between Rust and Go could possibly be explained by a difference in memory allocator used. Rust defaults to the system allocator, while Go ships with it's own memory allocator. Without using a memory profiler there is no way to know for sure that this is actually the reason.

[tgy3300]

It has been basically determined that it is the problem of mysql library. After changing sqlx library, the memory usage is only 0.5M

[erelde]

I think we should insist again that you measure with a profiler, not the windows task manager. On windows I think you can set up Visual Studio (not VScode) to do that with Rust. You should Google that.