# re: \[personal kdb+\] reducing k() overhead **URL:** \ **Category:** Community Support\ **Tags:** imported, kdb-and-q\ **Created:** [November 27, 2012, 11:57am UTC](https://forum.kx.com/t/re-personal-kdb-reducing-k-overhead/8009 "2012-11-27T11:57:00Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![Ryan\_Hamilton](https://avatars.discourse-cdn.com/v4/letter/r/439d5e/32.png) [@Ryan\_Hamilton](https://forum.kx.com/u/Ryan_Hamilton)\ **Post date:** [November 27, 2012, 11:57am UTC](https://forum.kx.com/t/re-personal-kdb-reducing-k-overhead/8009/1 "2012-11-27T11:57:00Z")
Hi, Instead of calling it for single atoms, create vector versions of functions. Overhead remains the same but is spread over the 1000’s of data points. In your case this would become: \ts do[1; f M#0] - Ryan * * * **From** : “Jay Han” \ **Sent** : Tuesday, November 27, 2012 7:26 AM **To** : [personal-kdbplus@googlegroups.com](mailto:personal-kdbplus@googlegroups.com) **Subject** : [personal kdb+] reducing k() overhead I have a shared library in c that calls q with k(). I notice that k() is relatively expensive. Is there any way to make it faster? Thanks! : air:q ; cat b.c // derived from http://kx.com/q/c/c/a.c // clang -Wall -Wextra -m32 -bundle -undefined dynamic\_lookup -L./m32 b.c -o m32/b.so #include \ #include"k.h" K f(K x){return ki(x-\>i+1);}  // q calls c K g(K x){return k(0,“1+”,r1(x),0);} // c calls q K h(K x){return k(0,“fq”,r1(x),0);} // ditto; fq:{:1+x} in b.q : air:q ; cat b.q f:`b 2:(`f;1) g:`b 2:(`g;1) fq:{:1+x} h:`b 2:(`h;1) M:1000\*1000 \ts do[M; f 0] \ts do[M; ff:f 0] \ts do[M; g 0] \ts do[M; gg:g 0] \ts do[M; h 0] \ts do[M; hh:h 0] \ : air:q ; q b.q KDB+ 2.8 2012.09.02 Copyright (C) 1993-2012 Kx Systems m32/ 2()core 4096MB hjh air.local 10.0.1.2 PLAY 2012.12.01  404 592j 661 704j 5810 592j / c calling q is not cheap 5019 704j 5194 592j 6442 704j : air:q ;  – Submitted via Google Groups ---
**Author:** ![jayhan](https://avatars.discourse-cdn.com/v4/letter/j/2bfe46/32.png) [@jayhan](https://forum.kx.com/u/jayhan)\ **Post date:** [November 27, 2012, 3:37pm UTC](https://forum.kx.com/t/re-personal-kdb-reducing-k-overhead/8009/2 "2012-11-27T15:37:00Z")
That’s is one possible answer.  However, an event loop or data points from unknown future timestamps wouldn’t easily yield to this approach. (Well, it’s not impossible – binning functions by  latency/timeout and applying them to a segment of data is possible workaround, but a bit convoluted. :-) kx.com/FD folks: any comment on the 10x overhead of k() would be much appreciated! ---
**Author:** ![jack31](https://avatars.discourse-cdn.com/v4/letter/j/58956e/32.png) [@jack31](https://forum.kx.com/u/jack31)\ **Post date:** [November 28, 2012, 11:15am UTC](https://forum.kx.com/t/re-personal-kdb-reducing-k-overhead/8009/3 "2012-11-28T11:15:00Z")
Hi Jay, \> comment on the 10x overhead of k() One contributor to the overhead is calling a function in a shared object. You can discover the overhead by using pure c: # ======== a.c f(void); main() { return f(); } ======== b.c f() { return 39; } Compare the run time of two cases where you statically link (cc a.c b.c -o c) and where you dynamically link in f(). I'm pretty sure you'll see a big difference. Ta, Jack.