<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Working with Large ADO.NET DataSets</title>
	<atom:link href="http://bobondevelopment.com/2007/10/23/working-with-large-adonet-datasets/feed/" rel="self" type="application/rss+xml" />
	<link>http://bobondevelopment.com/2007/10/23/working-with-large-adonet-datasets/</link>
	<description>Musings on the craft and business of software development</description>
	<lastBuildDate>Thu, 26 Aug 2010 03:21:57 -0600</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.6</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: liviu</title>
		<link>http://bobondevelopment.com/2007/10/23/working-with-large-adonet-datasets/comment-page-1/#comment-2853</link>
		<dc:creator>liviu</dc:creator>
		<pubDate>Wed, 24 Oct 2007 21:42:32 +0000</pubDate>
		<guid isPermaLink="false">http://bobondevelopment.com/2007/10/23/working-with-large-adonet-datasets/#comment-2853</guid>
		<description>I think at large processing the GC is showing its weakness, or better, the fact that data IS NOT allocated on the stack.
Stack is so easy to rewind....
Sometimes i think of the possibility to write data access in C++...

&lt;i&gt;Bob responds:  I don&#039;t know that the GC is showing an inherent weakness so much as that it&#039;s tuned for other, more common use cases.  Arguably, this issue also shows a downside of making string immutable, but rumblings I&#039;ve heard coming out of Microsoft recently suggest that more immutable collections and objects are in our future, essentially trading memory for thread safety and ease of use.

Something I wish for: a lightweight DataTable without all the versioning cruft and probably with some other little-used features jettisoned.  The latter wouldn&#039;t be read-only, but it&#039;d just have one version of each row, without commit / rollback functionality.  For many uses, that&#039;s enough.  It would have a smaller memory footprint and slightly better performance, and would tend not to create so much fragmentation in the first place.  In addition I&#039;d love to see a full-featured DataSet like we already have, but that uses a physical disk file or a DB table for its backing store -- in other words, a DataSet of infinite size -- like a DataReader, but able to be navigated at will in any direction.&lt;/i&gt;</description>
		<content:encoded><![CDATA[<p>I think at large processing the GC is showing its weakness, or better, the fact that data IS NOT allocated on the stack.<br />
Stack is so easy to rewind&#8230;.<br />
Sometimes i think of the possibility to write data access in C++&#8230;</p>
<p><i>Bob responds:  I don&#8217;t know that the GC is showing an inherent weakness so much as that it&#8217;s tuned for other, more common use cases.  Arguably, this issue also shows a downside of making string immutable, but rumblings I&#8217;ve heard coming out of Microsoft recently suggest that more immutable collections and objects are in our future, essentially trading memory for thread safety and ease of use.</p>
<p>Something I wish for: a lightweight DataTable without all the versioning cruft and probably with some other little-used features jettisoned.  The latter wouldn&#8217;t be read-only, but it&#8217;d just have one version of each row, without commit / rollback functionality.  For many uses, that&#8217;s enough.  It would have a smaller memory footprint and slightly better performance, and would tend not to create so much fragmentation in the first place.  In addition I&#8217;d love to see a full-featured DataSet like we already have, but that uses a physical disk file or a DB table for its backing store &#8212; in other words, a DataSet of infinite size &#8212; like a DataReader, but able to be navigated at will in any direction.</i></p>
]]></content:encoded>
	</item>
</channel>
</rss>
