localdata / nodetiles-core Goto Github PK

Per @mr0gorg's comment:

"In most engines, Array.length is calculated dynamically, so you should never use it in the loop's condition during performance-sensitive operations. Something like this is often much faster:

for (var i = 0, len = features.length; i < len; i++) {

This way, the length value is pre-computed and cached in len."

Maybe ship the repo with a mongodump?

The pipeline for filtered / non-filtered data is redundant; doubly so when you count the pipeline for UTF grids vs tiles vs tilejson.

Via @prashtx:

I was poking around for a way to get skip BSON parsing in the node mongodb driver. I found some interesting things on this page that could pertain to nodetiles/our performance investigations.
http://mongodb.github.io/node-mongodb-native/api-generated/cursor.html

In particular:

The raw flag might let us skip BSON parsing, but let's check the source to be sure. We can't use that data efficiently, but it'll help us better understand the "mongo time" piece of the puzzle.

The showDiskLoc flag might show us if we're doing a bunch of random reads for each request. On the mongolab shared plan, I'm pretty sure we're effectively using a magnetic hard drive underneath, as opposed to SSD.

The exhaust flag might avoid some round trips to issue the getMore requests.

If I get a chance to test these, I'll let you know.

in cartoRenderer around line 1275, max zoom needs an additional check to function correctly, like so:

      if (!maxZoom && minZoom && !(supportedZooms & (1 << i))) {
        console.log(minZoom, maxZoom);
        maxZoom = i - 1;
      }

Without if(!maxZoom ... , the maxZoom value will continue to increment with every loop.

https://github.com/LocalData/nodetiles-core/blob/master/lib/projector.js#L59

cc @prashtx

Per comment here 4ec36fa#commitcomment-3196430

For clarity / per the evolving NT standard.

If we request a tile + a grid, the data will be fetched twice.

We could:

• Cache the data
• Render the grid at the same time as the tile, and keep track if we're doing that so simultaneous requests will still get a response (albeit late)