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.

Sign up for GitHub

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

Jump to bottom

Zero-copy mapcache output when creating response Buffer #3

Open
homme opened this issue Mar 20, 2013 · 2 comments
Open

Zero-copy mapcache output when creating response Buffer #3

homme opened this issue Mar 20, 2013 · 2 comments
Labels
enhancement

Comments

@homme
Copy link
Member

homme commented Mar 20, 2013

This is analagous to geo-data/node-mapserv#5 with the difference that the free_callback would wrap apr_pool_destroy() in void MapCache::GetRequestAfter(uv_work_t *req).

Also, when calling apr_pool_create() in Handle<Value> MapCache::GetAsync(const Arguments& args) the pool should probably be created from MapCache::global_pool instead of cache->config->pool as the latter is destroyed when a MapCache instance is garbage collected: this could conceivably happen before the Buffer object is collected.
homme pushed a commit that referenced this issue Mar 21, 2013
Zero-copy mapcache output when creating response Buffer
7077bd8 
This fixes issue #3 with benchmarks showing a slight performance
boost.  A side effect is that the memory pool allocated for the
mapcache response is now cleaned up during the V8 garbage collection
cycle instead of at the end of each request as was previously the
case.
@homme
Copy link
Member Author

homme commented Mar 21, 2013

Fixed in 7077bd8. A side effect is that the memory pool allocated for the mapcache response is now cleaned up during the V8 garbage collection cycle instead of at the end of each request as was previously the case.

@homme homme closed this as completed Mar 21, 2013
@homme
Copy link
Member Author

homme commented May 9, 2013

7077bd8 passed local tests but failed on Travis-CI so was reverted: further investigation required...

@homme homme reopened this May 9, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@homme