LUA script engine for speedprofiles #1
Labels
Milestone
Comments
This was referenced Nov 25, 2011
Closed
|
Moving to 0.4 |
|
A first prototype is running here that uses a speedprofile defined by a LUA script. Will be moved to a seperate dev-branch in the near future. |
|
cool! |
This was referenced Jul 10, 2012
Closed
Closed
|
I was thinking today to also experiment with a JavaScript library to see what works best. |
|
cool. i think js would be easier for a lot of people, since it's so widespread. plus you can use coffeescript :-) |
|
what's the performance of running lua vs js? |
|
I haven't run any tests yet, but I suspect that both fair well. I am more thinking of usability and maintainability. @karme Any objections to using JavaScript? |
|
i agree usability and maintainability are probably more important that raw speed. but perhaps js offer all three things |
|
Project OSRM notifications@github.com writes:
fine with me |
|
I must conclude that Googles V8 is a pain after two days of working with it. |
|
can you say more? hard to compile, bad performance..? |
|
It is hard to integrate into existing code that was not built with V8 in mind. Also, the amount of additional wrapping code around it is not trivial. On the other hand, it took half an hour and 15 lines of code to get basic functionality with LUA. I will investigate further what the performance of LUA. |
|
thanks for explaining. |
This was referenced Sep 13, 2015
Closed
daniel-j-h
added a commit
that referenced
this issue
Feb 14, 2017
Here's all I could get out of a instrumented `osrm-partition`; debug build,
with all the bells and whistles I could think of to make it more verbose:
```
==17928==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 1560 byte(s) in 3 object(s) allocated from:
#0 0x7f4244185b30 in operator new[](unsigned long) ../../../../libsanitizer/asan/asan_new_delete.cc:62
#1 0x7f4242a788b3 (/usr/lib/libtbb.so.2+0x208b3)
SUMMARY: AddressSanitizer: 1560 byte(s) leaked in 3 allocation(s).<Paste>
``
Symbolizing the address results in
```
echo "/usr/lib/libtbb.so 0x7f4242a788b3" | llvm-symbolizer
_fini
```
Looks like a crt finalizer => static global dtor "leaking" from tbb.
Which turned out to be a missing `tbb::task_scheduler_init` on our end:
> Using task_scheduler_init is optional in Intel® Threading Building
> Blocks (Intel® TBB) 2.2. By default, Intel TBB 2.2 automatically creates
> a task scheduler the first time that a thread uses task scheduling
> services and destroys it when the last such thread exits.
https://www.threadingbuildingblocks.org/docs/help/hh_goto.htm?index.htm#reference/task_scheduler/task_scheduler_init_cls.html
Without an explicit instanz the first call to a tbb algorithm seem to initialize
a global scheduler singleton which then "leaks" until the program exits.
Phew.
MoKob
pushed a commit
that referenced
this issue
Feb 14, 2017
Here's all I could get out of a instrumented `osrm-partition`; debug build,
with all the bells and whistles I could think of to make it more verbose:
```
==17928==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 1560 byte(s) in 3 object(s) allocated from:
#0 0x7f4244185b30 in operator new[](unsigned long) ../../../../libsanitizer/asan/asan_new_delete.cc:62
#1 0x7f4242a788b3 (/usr/lib/libtbb.so.2+0x208b3)
SUMMARY: AddressSanitizer: 1560 byte(s) leaked in 3 allocation(s).<Paste>
``
Symbolizing the address results in
```
echo "/usr/lib/libtbb.so 0x7f4242a788b3" | llvm-symbolizer
_fini
```
Looks like a crt finalizer => static global dtor "leaking" from tbb.
Which turned out to be a missing `tbb::task_scheduler_init` on our end:
> Using task_scheduler_init is optional in Intel® Threading Building
> Blocks (Intel® TBB) 2.2. By default, Intel TBB 2.2 automatically creates
> a task scheduler the first time that a thread uses task scheduling
> services and destroys it when the last such thread exits.
https://www.threadingbuildingblocks.org/docs/help/hh_goto.htm?index.htm#reference/task_scheduler/task_scheduler_init_cls.html
Without an explicit instanz the first call to a tbb algorithm seem to initialize
a global scheduler singleton which then "leaks" until the program exits.
Phew.
MoKob
pushed a commit
that referenced
this issue
Feb 15, 2017
Here's all I could get out of a instrumented `osrm-partition`; debug build,
with all the bells and whistles I could think of to make it more verbose:
```
==17928==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 1560 byte(s) in 3 object(s) allocated from:
#0 0x7f4244185b30 in operator new[](unsigned long) ../../../../libsanitizer/asan/asan_new_delete.cc:62
#1 0x7f4242a788b3 (/usr/lib/libtbb.so.2+0x208b3)
SUMMARY: AddressSanitizer: 1560 byte(s) leaked in 3 allocation(s).<Paste>
``
Symbolizing the address results in
```
echo "/usr/lib/libtbb.so 0x7f4242a788b3" | llvm-symbolizer
_fini
```
Looks like a crt finalizer => static global dtor "leaking" from tbb.
Which turned out to be a missing `tbb::task_scheduler_init` on our end:
> Using task_scheduler_init is optional in Intel® Threading Building
> Blocks (Intel® TBB) 2.2. By default, Intel TBB 2.2 automatically creates
> a task scheduler the first time that a thread uses task scheduling
> services and destroys it when the last such thread exits.
https://www.threadingbuildingblocks.org/docs/help/hh_goto.htm?index.htm#reference/task_scheduler/task_scheduler_init_cls.html
Without an explicit instanz the first call to a tbb algorithm seem to initialize
a global scheduler singleton which then "leaks" until the program exits.
Phew.
MoKob
pushed a commit
that referenced
this issue
Feb 15, 2017
Here's all I could get out of a instrumented `osrm-partition`; debug build,
with all the bells and whistles I could think of to make it more verbose:
```
==17928==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 1560 byte(s) in 3 object(s) allocated from:
#0 0x7f4244185b30 in operator new[](unsigned long) ../../../../libsanitizer/asan/asan_new_delete.cc:62
#1 0x7f4242a788b3 (/usr/lib/libtbb.so.2+0x208b3)
SUMMARY: AddressSanitizer: 1560 byte(s) leaked in 3 allocation(s).<Paste>
``
Symbolizing the address results in
```
echo "/usr/lib/libtbb.so 0x7f4242a788b3" | llvm-symbolizer
_fini
```
Looks like a crt finalizer => static global dtor "leaking" from tbb.
Which turned out to be a missing `tbb::task_scheduler_init` on our end:
> Using task_scheduler_init is optional in Intel® Threading Building
> Blocks (Intel® TBB) 2.2. By default, Intel TBB 2.2 automatically creates
> a task scheduler the first time that a thread uses task scheduling
> services and destroys it when the last such thread exits.
https://www.threadingbuildingblocks.org/docs/help/hh_goto.htm?index.htm#reference/task_scheduler/task_scheduler_init_cls.html
Without an explicit instanz the first call to a tbb algorithm seem to initialize
a global scheduler singleton which then "leaks" until the program exits.
Phew.
MoKob
pushed a commit
that referenced
this issue
Feb 17, 2017
Here's all I could get out of a instrumented `osrm-partition`; debug build,
with all the bells and whistles I could think of to make it more verbose:
```
==17928==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 1560 byte(s) in 3 object(s) allocated from:
#0 0x7f4244185b30 in operator new[](unsigned long) ../../../../libsanitizer/asan/asan_new_delete.cc:62
#1 0x7f4242a788b3 (/usr/lib/libtbb.so.2+0x208b3)
SUMMARY: AddressSanitizer: 1560 byte(s) leaked in 3 allocation(s).<Paste>
``
Symbolizing the address results in
```
echo "/usr/lib/libtbb.so 0x7f4242a788b3" | llvm-symbolizer
_fini
```
Looks like a crt finalizer => static global dtor "leaking" from tbb.
Which turned out to be a missing `tbb::task_scheduler_init` on our end:
> Using task_scheduler_init is optional in Intel® Threading Building
> Blocks (Intel® TBB) 2.2. By default, Intel TBB 2.2 automatically creates
> a task scheduler the first time that a thread uses task scheduling
> services and destroys it when the last such thread exits.
https://www.threadingbuildingblocks.org/docs/help/hh_goto.htm?index.htm#reference/task_scheduler/task_scheduler_init_cls.html
Without an explicit instanz the first call to a tbb algorithm seem to initialize
a global scheduler singleton which then "leaks" until the program exits.
Phew.
oxidase
pushed a commit
that referenced
this issue
Feb 21, 2017
Here's all I could get out of a instrumented `osrm-partition`; debug build,
with all the bells and whistles I could think of to make it more verbose:
```
==17928==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 1560 byte(s) in 3 object(s) allocated from:
#0 0x7f4244185b30 in operator new[](unsigned long) ../../../../libsanitizer/asan/asan_new_delete.cc:62
#1 0x7f4242a788b3 (/usr/lib/libtbb.so.2+0x208b3)
SUMMARY: AddressSanitizer: 1560 byte(s) leaked in 3 allocation(s).<Paste>
``
Symbolizing the address results in
```
echo "/usr/lib/libtbb.so 0x7f4242a788b3" | llvm-symbolizer
_fini
```
Looks like a crt finalizer => static global dtor "leaking" from tbb.
Which turned out to be a missing `tbb::task_scheduler_init` on our end:
> Using task_scheduler_init is optional in Intel® Threading Building
> Blocks (Intel® TBB) 2.2. By default, Intel TBB 2.2 automatically creates
> a task scheduler the first time that a thread uses task scheduling
> services and destroys it when the last such thread exits.
https://www.threadingbuildingblocks.org/docs/help/hh_goto.htm?index.htm#reference/task_scheduler/task_scheduler_init_cls.html
Without an explicit instanz the first call to a tbb algorithm seem to initialize
a global scheduler singleton which then "leaks" until the program exits.
Phew.
oxidase
pushed a commit
that referenced
this issue
Feb 28, 2017
Here's all I could get out of a instrumented `osrm-partition`; debug build,
with all the bells and whistles I could think of to make it more verbose:
```
==17928==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 1560 byte(s) in 3 object(s) allocated from:
#0 0x7f4244185b30 in operator new[](unsigned long) ../../../../libsanitizer/asan/asan_new_delete.cc:62
#1 0x7f4242a788b3 (/usr/lib/libtbb.so.2+0x208b3)
SUMMARY: AddressSanitizer: 1560 byte(s) leaked in 3 allocation(s).<Paste>
``
Symbolizing the address results in
```
echo "/usr/lib/libtbb.so 0x7f4242a788b3" | llvm-symbolizer
_fini
```
Looks like a crt finalizer => static global dtor "leaking" from tbb.
Which turned out to be a missing `tbb::task_scheduler_init` on our end:
> Using task_scheduler_init is optional in Intel® Threading Building
> Blocks (Intel® TBB) 2.2. By default, Intel TBB 2.2 automatically creates
> a task scheduler the first time that a thread uses task scheduling
> services and destroys it when the last such thread exits.
https://www.threadingbuildingblocks.org/docs/help/hh_goto.htm?index.htm#reference/task_scheduler/task_scheduler_init_cls.html
Without an explicit instanz the first call to a tbb algorithm seem to initialize
a global scheduler singleton which then "leaks" until the program exits.
Phew.
TheMarex
pushed a commit
that referenced
this issue
Mar 1, 2017
Here's all I could get out of a instrumented `osrm-partition`; debug build,
with all the bells and whistles I could think of to make it more verbose:
```
==17928==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 1560 byte(s) in 3 object(s) allocated from:
#0 0x7f4244185b30 in operator new[](unsigned long) ../../../../libsanitizer/asan/asan_new_delete.cc:62
#1 0x7f4242a788b3 (/usr/lib/libtbb.so.2+0x208b3)
SUMMARY: AddressSanitizer: 1560 byte(s) leaked in 3 allocation(s).<Paste>
``
Symbolizing the address results in
```
echo "/usr/lib/libtbb.so 0x7f4242a788b3" | llvm-symbolizer
_fini
```
Looks like a crt finalizer => static global dtor "leaking" from tbb.
Which turned out to be a missing `tbb::task_scheduler_init` on our end:
> Using task_scheduler_init is optional in Intel® Threading Building
> Blocks (Intel® TBB) 2.2. By default, Intel TBB 2.2 automatically creates
> a task scheduler the first time that a thread uses task scheduling
> services and destroys it when the last such thread exits.
https://www.threadingbuildingblocks.org/docs/help/hh_goto.htm?index.htm#reference/task_scheduler/task_scheduler_init_cls.html
Without an explicit instanz the first call to a tbb algorithm seem to initialize
a global scheduler singleton which then "leaks" until the program exits.
Phew.
TheMarex
pushed a commit
that referenced
this issue
Mar 1, 2017
Here's all I could get out of a instrumented `osrm-partition`; debug build,
with all the bells and whistles I could think of to make it more verbose:
```
==17928==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 1560 byte(s) in 3 object(s) allocated from:
#0 0x7f4244185b30 in operator new[](unsigned long) ../../../../libsanitizer/asan/asan_new_delete.cc:62
#1 0x7f4242a788b3 (/usr/lib/libtbb.so.2+0x208b3)
SUMMARY: AddressSanitizer: 1560 byte(s) leaked in 3 allocation(s).<Paste>
``
Symbolizing the address results in
```
echo "/usr/lib/libtbb.so 0x7f4242a788b3" | llvm-symbolizer
_fini
```
Looks like a crt finalizer => static global dtor "leaking" from tbb.
Which turned out to be a missing `tbb::task_scheduler_init` on our end:
> Using task_scheduler_init is optional in Intel® Threading Building
> Blocks (Intel® TBB) 2.2. By default, Intel TBB 2.2 automatically creates
> a task scheduler the first time that a thread uses task scheduling
> services and destroys it when the last such thread exits.
https://www.threadingbuildingblocks.org/docs/help/hh_goto.htm?index.htm#reference/task_scheduler/task_scheduler_init_cls.html
Without an explicit instanz the first call to a tbb algorithm seem to initialize
a global scheduler singleton which then "leaks" until the program exits.
Phew.
This was referenced Sep 17, 2017
Closed
Closed
Closed
felixguendling
added a commit
to motis-project/osrm-backend
that referenced
this issue
Mar 27, 2020
…nd_yarn/eslint-6.8.0 Bump eslint from 2.13.1 to 6.8.0
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The extractor should be able to support scriptable speed profiles.
The text was updated successfully, but these errors were encountered: