Socket

[cainthebest]

1. Use explicit type annotations - Explicit type annotations can sometimes improve the performance of Rust code, as the compiler doesn't need to infer the type. For example, in the TcpSocket new() method, you can explicitly annotate the socket variable with the net::TcpStream type:

let socket: net::TcpStream = net::TcpStream::connect(complete_address).map_err(|_| SocketConnect)?;

2. Avoid dynamic memory allocation - In the receive() method of both TcpSocket and UdpSocket, you are dynamically allocating a Vec to hold the received data. This can be slow if the data is large, as the allocator needs to find a suitable block of memory. Instead, consider passing in a pre-allocated buffer to the receive() method. For example:

fn receive(&mut self, buffer: &mut [u8]) -> GDResult<usize> {
    self.socket.read(buffer).map_err(|_| PacketReceive)?;
    Ok(buffer.len())
}

3. Use the copy_from_slice() method - In the send() method of TcpSocket and UdpSocket, you are copying data from a slice into a buffer using a loop. This can be slow if the data is large, as each iteration of the loop incurs some overhead. Instead, consider using the copy_from_slice() method to copy the data in one go. For example:

fn send(&mut self, data: &[u8]) -> GDResult<()> {
    let mut buf = [0; DEFAULT_PACKET_SIZE];
    buf[..data.len()].copy_from_slice(data);
    self.socket.send_to(&buf[..data.len()], &self.complete_address).map_err(|_| PacketSend)?;
    Ok(())
}

4. Avoid unnecessary heap allocations - In the new() method of UdpSocket, you are allocating a String to hold the complete address, even though you only need it temporarily. Instead, consider using a stack-allocated buffer to format the address, like this:

fn new(address: &str, port: u16) -> GDResult<Self> {
    let mut buf = [0; 22];
    let len = write!(&mut buf[..], "{}:{}", address, port).unwrap();
    let complete_address = String::from_utf8_lossy(&buf[..len]).to_string();
    let socket = net::UdpSocket::bind("0.0.0.0:0").map_err(|_| SocketBind)?;

    Ok(Self {
        socket,
        complete_address
    })
}

5. Use a fixed-size buffer for receive - In the receive() method of UdpSocket, you are allocating a new Vec to hold the received data, even though you know the size of the data in advance. Instead, consider using a fixed-size buffer and returning only the actual data received. For example:

fn receive(&mut self, size: usize) -> GDResult<Vec<u8>> {
    let mut buf = [0; DEFAULT_PACKET_SIZE];
    let (number_of_bytes_received, _) = self.socket.recv_from(&mut buf).map_err(|_| PacketReceive)?;
    Ok(buf[..number_of_bytes_received].to_vec())
}

[CosminPerRam]

1. Moved directly inside Self constructor, also, isn't this something that the compiler has to figure out? How does it might improve performance in this scenario?

2. I have done that to provide the most clean use of the function, I find it rather a bit dirtier to be needed to provide your own pre-allocated buffer, but I'm considering this.

3. I don't understand what do you mean, this is the current send function of UdpSocket:

fn send(&mut self, data: &[u8]) -> GDResult<()> {
    self.socket.send_to(data, &self.complete_address).map_err(|_| PacketSend)?;
    Ok(())
}

where does the copying using a loop occurs?

4. Temporarily? I always use it in send for send_to, I also think this is something that could go into address_and_port_as_string instead.

5. I sometimes depend on the passed size parameter, which I cannot use as it isn't const, setting a default packet size to a too big value would be wasteful, while if it is too small, some packets will exceed its size.

Thanks a lot for the suggestions, and again, please DO correct me if I got something wrong!

[cainthebest]

1. The compiler can usually infer types, so it's not always necessary to provide explicit type annotations. However, there are cases where providing explicit types can help the compiler generate better optimized code. This is because when the compiler knows the exact type of a variable or expression, it can sometimes make more efficient decisions about how to represent and manipulate that value in memory.

2. Dynamic memory allocation is a powerful feature, but it can be relatively slow compared to stack allocation or pre-allocation. This is because when memory is allocated dynamically, the allocator needs to find a suitable block of memory and perform bookkeeping to keep track of allocated and deallocated memory. In cases where the size of the data to be stored is known in advance, it's often faster to use stack allocation or pre-allocation.

3. I made a mistake on how the data is used upstream and just ignore this idea.

4. Yeah this seems more suited for address_and_port_as_string, my point was that heap allocations can be fairly slow compared to stack allocation. In the new() method, a temporary String is created to hold the complete address. Since the address is only needed temporarily to create the socket, it can be more efficient to use a stack-allocated buffer instead of a heap-allocated String.

5. Yes while this is good if the size of the data is not known in advance, it can be less efficient than using a fixed-size buffer if the size is known. By using a fixed-size buffer, unnecessary heap allocations can be avoided and potentially improve performance.