Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use std.Buffer even less #4665

Closed
wants to merge 7 commits into from
Closed

Conversation

daurnimator
Copy link
Collaborator

Followup to #4405

@daurnimator daurnimator added the standard library This issue involves writing Zig code for the standard library. label Mar 7, 2020
@daurnimator daurnimator force-pushed the less-buffer branch 5 times, most recently from ce18696 to fe69332 Compare March 12, 2020 14:02
Copy link
Member

@andrewrk andrewrk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, I do think these are some nice changes. Some adjustments to make and then it's good to merge.

lib/std/child_process.zig Outdated Show resolved Hide resolved
lib/std/target.zig Outdated Show resolved Hide resolved
@@ -967,23 +967,23 @@ pub const Target = struct {

pub const stack_align = 16;

pub fn zigTriple(self: Target, allocator: *mem.Allocator) ![:0]u8 {
pub fn zigTriple(self: Target, allocator: *mem.Allocator) ![]u8 {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 These I agree to change

Copy link
Member

@andrewrk andrewrk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

almost there

Comment on lines -10563 to -10553
cache_str(ch, g->libc->include_dir);
cache_str(ch, g->libc->sys_include_dir);
cache_str(ch, g->libc->crt_dir);
cache_str(ch, g->libc->msvc_lib_dir);
cache_str(ch, g->libc->kernel32_lib_dir);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These need the separator, otherwise a/b/ c/d would hash the same as a/b /c/d.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ooo interesting. that that mean that cache_mem should also mix in the length?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe cache_mem is used internally as "put these bytes into the hash", whereas the public API functions are more along the lines of "put this thing in the hash and make sure it's separate"

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Then perhaps that belongs in the cache_slice function below and hence answers you question there :)

Comment on lines 33 to 38
void cache_slice(CacheHash *ch, Slice<const char> slice) {
cache_mem(ch, slice.ptr, slice.len);
}

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do we need this API? why not use cache_mem directly?

Comment on lines 377 to 378
var result_buf = std.ArrayList(u8).init(allocator);
defer result_buf.deinit();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is less efficient use of memory here. Before it only made one byte buffer and resized it in the loop; now it allocates and frees a fresh one every loop iteration. Why not port the code directly using ArrayList?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Depends on your allocator

  • For smart allocators that use a freelist, they will essentially do this automatically
  • For dumber allocator, each time through the loop may have a different sized allocation and they probably don't do realloc efficiently, so they end up doing multiple allocations anyway!

In general I have a preference to reduce the scope of variables as much as possible.

src/link.cpp Show resolved Hide resolved
Comment on lines +196 to +203
fn appendWrite(self: *Self, m: []const u8) !usize {
try self.appendSlice(m);
return m.len;
}

pub fn outStream(self: *Self) std.io.OutStream(*Self, error{OutOfMemory}, appendWrite) {
return .{ .context = self };
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's nice addition!
But maybe add a new structure with all necessary functions?
Something like std.io.MemoryStream.

@daurnimator daurnimator force-pushed the less-buffer branch 2 times, most recently from 775d89a to 5ef2d0f Compare March 31, 2020 12:15
@andrewrk
Copy link
Member

andrewrk commented Apr 1, 2020

This is merged now, with additionally the following (breaking) changes:

    std.Buffer => std.ArrayListSentineled(u8, 0)
    
    This new name (and the fact that it is a function returning a type) will
    make it more clear which use cases are better suited for ArrayList and
    which are better suited for ArrayListSentineled.
    
    Also for consistency with ArrayList,
     * `append` => `appendSlice`
     * `appendByte` => `append`
    
    Thanks daurnimator for pointing out the confusion of std.Buffer.

@andrewrk andrewrk added the breaking Implementing this issue could cause existing code to no longer compile or have different behavior. label Apr 1, 2020
@daurnimator daurnimator deleted the less-buffer branch April 1, 2020 21:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
breaking Implementing this issue could cause existing code to no longer compile or have different behavior. standard library This issue involves writing Zig code for the standard library.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants