Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!eternal-september.org!feeder.eternal-september.org!mx05.eternal-september.org!.POSTED!not-for-mail From: Eric Sosman Newsgroups: comp.lang.java.programmer Subject: Re: Efficiency/Reliablility of Scaled Up JTable Date: Mon, 29 Apr 2013 12:01:11 -0400 Organization: A noiseless patient Spider Lines: 44 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Mon, 29 Apr 2013 15:57:58 +0000 (UTC) Injection-Info: mx05.eternal-september.org; posting-host="0d73d8cc209bff1c6395088b400d0605"; logging-data="32542"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+cIl+mxyW5vyBGAnjRdwwZ" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 In-Reply-To: Cancel-Lock: sha1:FF0NOyrcTNhsNGvrNywb0gCqPaY= Xref: csiph.com comp.lang.java.programmer:23718 On 4/29/2013 11:26 AM, Daniel Pitts wrote: > On 4/29/13 5:13 AM, clusardi2k@aol.com wrote: >> If I have a JTable with a lot of colors, and if the application >> deletes and then adds columns to it will the performance degrade if I >> go from a 30 X 30 table to a 1000 X 100 table, please explain. >> >> Thanks, >> > It depends on the underlying TableModel implementation. Using the > default implementation, it is backed by a Vector of Vectors [1]. > A "random position" insert or remove in a vector is amortized to be an > O(N) operation. insert/remove at the end of a vector is O(1). > > Adding a row will create a brand new Vector, and insert that Vector into > the row Vector. remove a row will simply remove that row from the row > Vector. > > Adding or remove a column will need to iterate through all rows and > add/remove from each of the column Vectors. If this is the first > column, your worst case, this will be a O(N*M) operation. > [...] Good stuff. However, didn't the O.P. have a question a day or so ago about a "horizontally scrolling" table, where new columns appeared at the right while old ones vanished from the left (maybe with a few leftmost columns inviolate)? If that's the table in question, I think he'd do better to use a column-oriented model, where the vectors (not necessarily Vectors) run top-to-bottom instead of left-to-right. A benefit would be that inserting, deleting, and permuting columns could be done by I/D/P'ing the vector references instead of mucking with the individual cell contents. It all depends on which axis gets more activity. Alternatively, a HashMap,Object> might serve as model supporting both access directions equally well, and could handle row/column rearrangements quickly by storing "virtual" coordinates translated through a pair of arrays for the permutation of the moment. -- Eric Sosman esosman@comcast-dot-net.invalid