Hi Nick, Understood on the QCE version not being an issue. So in my
initial response to this I wasn't able to replicate the issue with
n:50000000, if you look at that you see I call position twice and the
heap returns to normal. For n:2000000 I see t...
I wasn't able to replicate the issue on my local machine running on KDB+
4.0 2020.07.15: My heap returned back to the level it was at the start
of the Q session on release as expected. However I was able to recreate
the issue running KDB+ 4.0 Cloud E...
As a simple starting point before investigating the data, type errors in
Q suggest that you have provided the wrong datatype to a function. In
the case of .Q.chk make sure you're passing in a filepath as per the
documentation which is a symbol type. ...
Hi Nick, Here are the steps I did to attempt reproducing your issue:
Host Machine (Port 5000): q)n:50000000
q)position:([]time:n?.z.p;sym:n?`ABC`APPL`WOW;x:n?10f) Client Machine:
q)h:hopen`::5000 q).Q.w[] used| 357632 heap| 67108864 peak| 67108864
wm...
Hi Nick, The previous comment of using .Q.w[] is a good start for
isolating what part of the calculations are memory intensive and
requiring a large heap allocation by the OS. Printing to standard out
using 0N! after each expected memory intensive li...
