On Tue, Nov 19, 2019 at 8:00 PM 'Rob Hodgkinson' via Programming <programm...@jsoftware.com> wrote: > The overhead associated with the multi key indexing you describe > below is impractical for low latency matching, and avoided by > managing a free space list for bucket re-use.
Why do you say that? (How big of a dataset does your UI represent? How fast is data arriving? And, if it's large, what are you showing to your users?) With a linked list, you have array elements scattered throughout memory, which tends to result in high overhead from cache misses. With an array, you have array elements densely packed, which gives high cache coherency. And, for something like list/array traversal, cache misses are order of magnitude more expensive than computation. (So it sounds like you might be working off of untested rumor, or maybe that your benchmarks did not involve good implementations or did not involve large data sets.) As a general rule, sorting does not take perceivable time in J unless you're working with datasets which are large enough that they would take years for one person to enter manually. (Or unless we're talking about secondary effects -- if it takes 30 milliseconds to sort a large dataset and you're doing animation such that you only have 10 milliseconds to prepare the next frame of imagery, that's a real problem, and getting things to work right there takes some effort and some complicating simplifications.) Put different: working with these kinds of issues can be tricky, and can involve issues that many people are not prepared to deal with. Consequently, people tend to favor a working implementation over any other implementation (which is fine, but it's a bad idea to generalize about reasons when you cannot adequately observe what you're working with). But we also get people repeating ideas (and working off of ideas) which don't actually play out in practice. On the other side of things, though, there's another issue to think about when working with J, which is the single threaded character of the implementation. Ideally, for UI work and significant computation, you want the UI to work independent from the computational engine -- the reason is that machines fail often enough and in so many different ways that people need to be reassured that the thing is still working. So, with J that might mean something like a javascript based UI and JHS. > I still believe that both an ordering attribute and also a > dictionary, would be very useful assets to an array language, but > would need to be implemented “natively” within the language to be > fully useful (not an add-on, but part of the language notation, as > per kdb+ for dictionaries for example). That could be, but (speaking personally): I am not going to optimize code that I don't have access to. Thanks, -- Raul ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
