Arlochorim 5 days{"ops":[{"insert":"Lately I've been using archidekt for making lists of cards I'd like to obtain for later reference and I've noticed that the website seems to slow down considerably with larger deck lists (above 1000 cards), this affects most features such as adding cards, dragging a card from one category to another, and even right clicking on cards.\n\nI've attempted to trouble shoot this by killing all processes for my browser and restarting in a new window to ensure the browser wasn't the cause, and when this didn't alleviate the issue I attempted to use a different browser.\n\nThe issue also occurs on my mobile device and my steam deck (using the desktop mode.\n\nSo far I've experienced the issue with chrome, edge and firefox, and on windows, android, and linux\n\nI'm unsure if this is due to the way the site retrieves and stores card data, as it appears to still persist when not using a visual display method, but it is beginning to limit my use of the site.\n\nMy primary PC hardware is unlikely to be the cause, as I have 32gb ram, a Ryzen 3600 processor and an ethernet internet connection of 1000/40 mbps\n"}]}
0
michael(Alpha User)
5 days{"ops":[{"insert":"The site isn't built for decks that are that large. Officially we only support list up to 200 unique cards, but we test with up to 300. Anything above that is sailing unknown waters. \n\nThe reason for the slowdown is likely due to a few things. \n\n1) There's a lot of images loaded. Your browser isn't built to render that many images on the page at once. Your browser doesn't like it when tabs use that much of a memory footprint. The browser will often kill tabs using too much memory as it can think there's a memory leak. Archidekt doesn't leak memory, but if you conitnue to add cards to the page, it can act like that. \n\n2) Archidekt's layout is relatively complex as far as webpages go. This takes more resources from the browser to render/ repaint as the viewport changes (either deck changes or scrolling). This isn't likely to put a strain on the underlying hardware. Moreso that the browser itself is not built to use that many resources per tab. \n\n3) The card data itself is relatively data intensive as far as webpages go. All card data needs to be available for the deck builder to function (card text being the largest). For 200+ cards, that memory footprint balloons. \n\nTo put it plainly, Archidekt isn't built for what you're using it for. We don't stop users from doing it sicne we didn't want to have to define an arbitrary upper limit, but there isn't much we can do to improve it the performance. Anecdotally, we've heard that not using the image mode can improve performance to a point, but even that will only take you so far (as you mentioned you've noticed). \n\nI think if you want this information to be stored in Archidekt, using the collection manager would be better suited to what you're using the site for. That is built for lists of up to +100k unique records. If you're already using the collection and don't want the data to conflict, you could create a label of something like \"wishlist\", and label all collection cards with that label that you don't yet own. \n\nI wish I had better news for you. We're always trying to improve performance of the deck building page. Any of which should bubble up to extremely sized decklists. But even then, we likely wouldn't end up testing decks larger than 200 unique cards since even that puts us in the 99.99th percentile of deck sizes. \n"}]}
2
Arlochorim 3 days{"ops":[{"insert":"I can appreciate that, I've found between many different sites that archidekt has the most useful fuzzy searches (as opposed to something like moxfield that trips up on minor errors), due to this archidekt tends to be Go-To for large list management.\n\nI work in a fairly high level IT development governance role, so I understand web development takes time and it's not always a good return on investment to develop something for what appears to be a small percentile of the userbase, but I wonder if the percentile data is impacted by survivorship bias due to other users encountering the same the issues I have, leading to the sentiment that it's not worth using the site for that purpose, resulting in the demographic appearing smaller than the actual percentage of users who would like to use that type of feature.\n\nIf I had to spit ball what the solution would look like in a perfect world, I'd envision something in between the text view in the current deck builder and the collection view. It could display the card name , quantity, set, price, condition, etc similar to what is already available in the collection view, but with collapsible sections to reduce data requiring display on initial load and only display the card images and details on mouseover/click. ideally if a user wanted to view cards in a stack/visual spoiler from this view, this could be selected by category to limit the card data that needs to be drawn at a single time. Other useful functionality would be to allow users turn off auto categories to make it easier to assign from \"unassigned\" into a relevant category, this could be for assigning cards from a generic wishlist, to specific decks without cluttering the specific deck view until the cards are obtained. and to highlight certain rows as required. \n\nAs for a way of viewing the lists, instead of one collection screen, something similar to moxfield's folder options allowing users to create multiple lists and store it in a sub-folder would be ideal.\n\nAnother option to reduce load times from the back end if it's not already being done may be to use a DBMS or RDBMS if your infrastructure/host supports it to cache the key information from the list, Card Id, Name, type, Text, P/T, category, allowing faster retrieval, this type of data isn't updated very frequently unlike price information, and the cache data would be likely to reduce calls to external platforms(unsure if card info is pulled using the scryfall API)\n\nRegarding the potential bias on the percentile date, for ways around this, I'd suggest a user survey on a platform like reddit to determine whether there is interest in this kind of additional functionality.\n\nAt the end of the day, I still love the site and will keep using it as I currently am, and the above is purely suggestion with no expectation that it will be implemented due to cost/effort/time/staff/hosting limitations.\n\n\n"}]}
0