@edvin maybe we can do the same thing with cellprovider/cache/fragment where you store fragments based on their model object allowing for empty objects that javafx might create

@carlw Wouldn't that create 1 million nodes if you scroll through a list with 1 million items?

@edvin I'm not sure....scroll through 1 million there are say 50 listCells

@edvin depends on if freeing the other 999,950 cells frees the model objects

Indeed.

the last time i checked when we were talking about RAM, i think things cleaned up pretty nicely

I think this issue is actually present in the other example apps as well, it's just slightly different there.

scroll produced a huge bump in memory usage, but the app would recover once the ListView went away

and if the ListView was still being used, we might want the RAM there anyway

Yes, but we don't want a node hierarchy for each item, for sure.

That's what cellCache does by the way, but this should be smarter.

I will keep pondering this and play more with it the coming days. It's almost midnight here so I gotta get some sleep 🙂

would the node hierarchy go away when the ListCells go away?

@carlw If you have one per item it would only go away when the cache goes away. The cache would be tied to the ListView so that means it would be gone when the ListView goes away I think.

To support large data structures it is only viable to have one fragment/node hierarchy per cell.

@edvin good point

@edvin do you think supporting a non-cache version would fix this? basically return a find(ItemFragment.class) that could be reclaimed when ListCell if freed?

@edvin I have a function readCache() which looks up the node hierarchy by business key (todoitem.id). i replaced that with something that skipped the map put() and it seemed to work

@edvin i realize you are offline, but could we add a chooseDirectory function in the Dialogs file? and add an initial directory parameter?

@User uploaded a file: Untitled

initial directory for both chooseFile and chooseDirectory? thanks..

@edvin initial directory for both chooseDirectory and chooseFile

@edvin i realize my return is messed up in the snipped above.. if the user doesn't select a directory an exception is thrown...

@edvin for the listcell cache...what would you think about scanning the cache for opportunities to undo the item bindings? when the cache is accessed, look through the fragments for any bound items?

Interesting article this group might enjoy https://kotlin.link/articles/Mimicking-Kotlin-Builders-in-Java-and-Python.html

nice article well written

@edvin when i get a chance tonight or this weekend, i’m going to try making the listview use a FixedFragmentPool instead of a cache. I’ve seen JavaFX create ListCells for the visible items plus a few extra, so I figure that i can create a circular linked list of ItemFragments, say 100, that the ListView will draw off of. This value can be configurable. When de-queuing an item, I’ll first clear out any itemProperty value which unbinds everything. This should give us the cleanup that we’re missing. Then, ListCell gets an ItemFragment that’s ready to be set without any extra bindings. I don’t see a way to manage a cache without a way to expire the items.

task

ignore that... mean to type in the search box 🙂

@carlw It's not needed. If you can write the code to do the cleanup, you could use the fragment approach right now. I'm onto something that manages all this behind the scenes though, so you don't even need to think about cleanup, and still would only have as many fragments as you have cells. Unfortunately, I've gotten a ton of work to deal with (we're moving in some large customers with lots of domains/emails/webs) so I'm stuck for some of the weekend with writing import routines etc. Hope to have time to finish this feature before the weekend though.