Skip to content

Conversation

jmarantz
Copy link
Contributor

@jmarantz jmarantz commented Feb 25, 2020

Description: Now that we take tags as a vector of StatName pairs, change the other args to also pass via StatName. This will reduce redundant converstions between string and StatName and also reduce acquisition of the symbol table lock.
Risk Level: low
Testing: //test/...
Docs Changes: n/a
Release Notes: n/a

Signed-off-by: Joshua Marantz <jmarantz@google.com>
Signed-off-by: Joshua Marantz <jmarantz@google.com>
Signed-off-by: Joshua Marantz <jmarantz@google.com>
Signed-off-by: Joshua Marantz <jmarantz@google.com>
Signed-off-by: Joshua Marantz <jmarantz@google.com>
jmarantz added 5 commits March 1, 2020 10:54
Signed-off-by: Joshua Marantz <jmarantz@google.com>
Signed-off-by: Joshua Marantz <jmarantz@google.com>
…kes.

Signed-off-by: Joshua Marantz <jmarantz@google.com>
… to StatName.

Signed-off-by: Joshua Marantz <jmarantz@google.com>
Signed-off-by: Joshua Marantz <jmarantz@google.com>
@jmarantz jmarantz changed the title WiP stats: avoid extra conversions between StatName and string. stats: cleanup APIs and avoid extra conversions between StatName and string. Mar 2, 2020
@jmarantz jmarantz marked this pull request as ready for review March 2, 2020 13:07
Copy link
Contributor

@snowp snowp left a comment

Choose a reason for hiding this comment

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

Thanks for this, just a few questions

void SymbolTableImpl::Encoding::appendToMemBlock(StatName stat_name,
MemBlockBuilder<uint8_t>& mem_block) {
const uint8_t* data = stat_name.dataIncludingSize();
if (data == nullptr) {
Copy link
Contributor

Choose a reason for hiding this comment

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

what's the use case for appending a stat name with no data? is this just to make it easier in test?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

no, empty constructor for null-stats and for when there is no tag-extracted-name.

This wasn't necessary before because a StatName constructed from "" didn't require this special-casing, but I wanted to allow StatName() to also work; without this it crashes.

@@ -516,7 +526,9 @@ void StatNameStorageSet::free(SymbolTable& symbol_table) {
SymbolTable::StoragePtr SymbolTableImpl::join(const StatNameVec& stat_names) const {
uint64_t num_bytes = 0;
for (StatName stat_name : stat_names) {
num_bytes += stat_name.dataSize();
if (!stat_name.empty()) {
Copy link
Contributor

Choose a reason for hiding this comment

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

why do we need this now?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

There are places in the code where elements being join()ed are empty, and we have been skipping these.

Here though we just have another case of an empty-constructed StatName() will crash now if we don't special-case this.

lizan and others added 3 commits March 2, 2020 14:27
Signed-off-by: Lizan Zhou <lizan@tetrate.io>
Signed-off-by: Joshua Marantz <jmarantz@google.com>
Signed-off-by: Joshua Marantz <jmarantz@google.com>
Signed-off-by: Joshua Marantz <jmarantz@google.com>
@@ -43,6 +43,13 @@ class MockDecoder : public Decoder {
MOCK_METHOD(void, onData, (Buffer::Instance & data));
};

class TestStatStore : public Stats::SymbolTableProvider, public Stats::IsolatedStoreImpl {
Copy link
Contributor

Choose a reason for hiding this comment

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

not used?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

done.

Signed-off-by: Joshua Marantz <jmarantz@google.com>
@jmarantz
Copy link
Contributor Author

jmarantz commented Mar 4, 2020

Thanks @snowp -- Matt you want to take a look at this one?

I don't think this is a candidate for force-merging, unlike #10245 , as this is not quite that trivial. But hopefully something else happens to master to resolve the coverage issues :)

Copy link
Member

@mattklein123 mattklein123 left a comment

Choose a reason for hiding this comment

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

LGTM, thanks. Do you want to merge master?

Signed-off-by: Joshua Marantz <jmarantz@google.com>
@mattklein123 mattklein123 merged commit 6da5308 into envoyproxy:master Mar 5, 2020
@jmarantz jmarantz deleted the stat-name-lists branch March 5, 2020 03:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants