This repository has been archived by the owner on Aug 8, 2023. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
1 parent
2d8bf82
commit 50b5c15
Showing
9 changed files
with
112 additions
and
297 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,24 +1,16 @@ | ||
#include <mbgl/map/geometry_tile.hpp> | ||
#include <mbgl/style/filter_expression_private.hpp> | ||
|
||
#include <iostream> | ||
namespace mbgl { | ||
|
||
using namespace mbgl; | ||
|
||
std::ostream& mbgl::operator<<(std::ostream& os, const GeometryFeatureType& type) { | ||
switch (type) { | ||
case GeometryFeatureType::Unknown: return os << "Unknown"; | ||
case GeometryFeatureType::Point: return os << "Point"; | ||
case GeometryFeatureType::LineString: return os << "LineString"; | ||
case GeometryFeatureType::Polygon: return os << "Polygon"; | ||
default: return os << "Invalid"; | ||
mapbox::util::optional<Value> GeometryTileFeatureExtractor::getValue(const std::string& key) const { | ||
if (key == "$type") { | ||
return Value(uint64_t(feature.getType())); | ||
} | ||
|
||
return feature.getValue(key); | ||
} | ||
|
||
std::ostream& mbgl::operator<<(std::ostream& os, const GeometryTileFeature& feature) { | ||
os << "Feature(" << feature.getID() << "): " << feature.getType() << std::endl; | ||
for (const auto& prop : feature.getProperties()) { | ||
os << " - " << prop.first << ": " << &prop.second << std::endl; | ||
} | ||
return os; | ||
template bool evaluate(const FilterExpression&, const GeometryTileFeatureExtractor&); | ||
|
||
} |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
50b5c15
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This commit made tile parsing significantly slower:
vs.
Note that both views are parsing the same set of tiles, but the new one takes about twice as long. The culprit seems to be iterating through features. The code removed in this commit did this in an efficient way by only parsing the required parts and quickly advancing to the next as soon as a match fails. The new code requires parsing the entire feature including all tags, before it can do a comparison. @jfirebaugh, can we revert this commit?
50b5c15
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This commit is necessary for annotations support, but I believe the interface can still support a lazier parsing strategy. I'll take a look at this today.
50b5c15
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there some way to monitor changes in performance so that these get flagged automatically?
50b5c15
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Performance regressions are really hard to catch because we would need to run them in a highly controlled environment (= not the cloud) to havE any sort of meaning. In addition, performance characteristics are different based on the architecture of the CPU. We're deploying this code on a vast number of architectures (x86, arm, mips, all with a 64 bit equivalent) as well.
50b5c15
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, what @kkaefer said, though once I finish #830 we may be able to automate some sorts of client-actions-triggering-parsers/renders-under-the-hood that we can measure with completion callbacks. It's a little shaky but maybe better than nothing.