Day 22: No More Heap Hoarding

“Blitzen, do you realize every single read_to_string() call triggers a fresh heap allocation? Do you think we’ve got infinite memory lying around?”

Here, I called it a few times and the process is taking up 1.5GB of memory, you think this is acceptable?

Blitzen glanced up, nonchalant. “Heap allocations happen, Santa. That’s life.”

Santa’s eyes narrowed. “Do you want the nightmare of Day 1 all over again? That disaster was just a simple string clone, and it nearly broke us. This? This is worse. Way worse. I don’t want to end up manually running drop() just to keep things from spiraling into chaos!”

Blitzen stiffened, finally taking the hint. “Okay, okay. What do you want me to do?”

Prancer cut in cautiously. “Why not cache the file content on every write? And return a reference to the cached content on every read?”

Blitzen nodded slowly. “Yeah, that’ll work. No more redundant allocations, no stale reads, and we don’t touch drop() at all.”

Santa’s glare softened—marginally. “Good. Make it lean, make it fast, and make sure it’s ready by sunrise. We don't have much time, Christmas is just around the corner.”

Your Mission

Santa's files are huge, and they use a lot of memory, To prevent that we need to create a new method named read_to_str that will return a string slice instead of an owned value.

Here is what you need to do:

Create a new field called content
Update the write method to update the content on every write
Complete the read_from_cache method to return a string slice instead of an owned value

Hints

If you’re unsure where to start, take a look at these tips:

Click to reveal hints!

Create a new field called content to store the file content

pub struct TempFile {
    file: File,
    file_path: PathBuf,
    content: Vec<u8>,
}

Update the field in file writes, use to_vec() to turn a &[u8] to a Vec<u8>
```
self.content = data.to_vec();
```
Use the std::str::from_utf8 function to convert a &[u8] to a &str
```
std::str::from_utf8(&self.content).unwrap_or("")
```

Editor not available on Mobile!

In order to solve the challenge, please visit this page on a desktop computer.

Comments

Luis Linares@lulingar3 days ago

I agree with @dyoo, I'm looking at the solutions from other people and they implement `write()` in such a way that only the data of the last call is what is saved into `content`.

Danny Yoo@dyoo9 days ago

The test cases also make an undefined assumption between the behavior of multiple calls to write on the file and the cached value that makes absolutely no sense. Specifically: when calling write() repeatedly, its action on the file is to continue to append to the existing content. However, the tests assume that only the very last write() saves into the cache. This trivially means that the cache and the file content can easily diverge. None of this feels right.

Danny Yoo@dyoo9 days ago

The problem also no longer makes much sense: if we're maintaining an in-memory cache, there's no need for the temporary file, no need to touch the file system.

Danny Yoo@dyoo9 days ago

The types are problematic with respect to Unicode: write() consumes data, which is an arbitrary byte slice. However, read_from_cache returns a &str. Byte slices and &str are *not* interchangable.