couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Randall Leeds (JIRA)" <>
Subject [jira] [Commented] (COUCHDB-1130) binary optimization in couch_file
Date Mon, 18 Apr 2011 22:31:06 GMT


Randall Leeds commented on COUCHDB-1130:

@Paul: I have no idea.
And looking at the docs I think I understand a bit better now.

I think what we're doing is akin to the second code example in
Except, according to that excerpt, even if we switched the argument order (as in my patch),
we avoid creating sub-binaries but we still create a extra match contexts.

This code path's only ever hit when we're pulling objects > 4096KB (?SIZE_BLOCK) out of
the couch file, and even then I expect the gains are quite small. But who knows. I'll try
to profile it in a bit. I'm super curious and I'm enjoying the education.

> binary optimization in couch_file
> ---------------------------------
>                 Key: COUCHDB-1130
>                 URL:
>             Project: CouchDB
>          Issue Type: Improvement
>          Components: Database Core
>    Affects Versions: 1.0.2
>            Reporter: Randall Leeds
>            Priority: Minor
>         Attachments: 0001-refactor-remove_block_prefixes-2-for-optimization.patch
> I've had this patch sitting around since January and kept forgetting to file the ticket.
Hurray spring cleaning.
> Just for fun I ran erlc with +bin_opt_info, which gives information about how the Erlang
VM can optimize creating binary objects.
> What follows is the commit message from my patch.
> Even if I'm wrong about the last point, it can't hurt.
> What think you all?
> -------------------
> Running erlc with +bin_opt_info gives an INFO message stating that "matching
> anything else but a plain variable to the left of a binary pattern will prevent
> delayed sub binary optimization; SUGGEST changing argument order"
> I guess matching 0 is triggering this. If I understand correctly, this change
> will allow the compiler to skip creating a sub-binary that starts at the block
> boundary in the third clause and delay creation until we strip the leading byte
> in the 0 clause. This means one less 1-byte binary every time we read across a
> block boundary.

This message is automatically generated by JIRA.
For more information on JIRA, see:

View raw message