No, maps don't use expanded tree cache space. A really large map might hit some per-eval limits, but I didn't find them when I created map around 800-MiB on my laptop, with 6.0-3. I used an xdmp:quote to try to make sure the map would really allocated more space for each entry. This was fine at 80-MiB and took about 5-sec. For 800-MiB it took a little longer, and the OS swapped some pages out. So I conclude that it was working hard to allocate all the memory.
let $m := map:map() let $n := doc()[1] let $_ := (1 to 1000000) ! ( map:put($m, xdmp:integer-to-hex(xdmp:random()), xdmp:quote($n))) return map:count($m) * string-length(xdmp:quote($n)) div (1024 * 1024) , xdmp:elapsed-time() => 802.04010009765625 PT1M6.429219S On that QA system, you might have set the expanded tree cache size to a smaller value on purpose. That can be a good way to catch poorly-optimized queries. -- Mike On 6 May 2013, at 14:44 , Will Thompson <[email protected]> wrote: > Here's another one related to the Expanded Tree Cache: Say I want to load > a giant map: 400MB or more. Will this always be dependent on the size of > the Expanded Tree Cache? Most of our dev machines have an Expanded Tree > Cache big enough to handle a map like this, but some don't, and for some > reason our QA server is set to an inexplicably small value. Is it > advisable to just manually increase that value so everything fits? Are > there any other general rules when adjusting server spec values? I have > mostly heard "look don't touch" with regard to these settings. > > -Will > > _______________________________________________ > General mailing list > [email protected] > http://developer.marklogic.com/mailman/listinfo/general > _______________________________________________ General mailing list [email protected] http://developer.marklogic.com/mailman/listinfo/general
