Испытания проводились "на коленке" :-)
1. Взял .shp файл (Road network, 1.2M записей, 12 аттрибутов)
2. Создал FileGeodatabase на том-же диске
3. Залил туда .shp
4. Открыл ArcMAP, добавил (1), засек время прорисовки
5. Сделал то-же с (2)
6. Сравнил время
Реально - я проводил несколько сравнений. С разными данными. Если аттрибутов или записей меньше - скорость падает не так сильно.
Вот ответ от ESRI Inc.
Thank you for your patience. I have tested various scenarios on various feature
classes here. I was able to dig up a feature class with over 12,000,000 points
in it, and as expected, the results I faced were similar to yours. Compacting
the database in the case of this data had virtually no effect on the rendering
speed of the data at all.
The next thing I tried was to remove the
attribute information from the table, except for three fields, five in the case
of the file geodatabase, on account of the Shape_Area and Shape_Length fields.
Once this was done, the file geodatabase started to catch up to the shapefile in
terms of performance.
The reason fro this was actually discussed in the
forum post that you sent me in one of your initial emails:
FGDB Slow,
Shapefile FAST! Why?
http://forums.esri.com/Thread.asp?c=93&f=985&t=259326
Lance
Shipman describes the data storage and access in a file geodatabase as opposed
to a shapefile.
We are all familiar with the fact that a shapefile is
composed, most critically, of a shp, shx and dbf. Shp stores the geometry
information while the dbf stores the attribute information, two separate files
that get accessed only as necessary. When we are displaying the data, or using
spatial functions that have nothing to do with attributes, the application
doesn't even bother with the dbf. The table will only be accessed when the
attribute information is needed.
In a file geodatabase, the geometry and
attribute information are stored together. When you add a file for rendering,
the application needs to read both the geometry and the attributes. This may be
enough to account for performance degradation in the file geodatabase, if there
are a large number of big fields (think long string fields). Unfortunately,
this is part of the structure of the file geodatabase and unless you can live
without your fields, will be something that needs to be accommodated.
The
other option to test, would be to export the shapefile into the geodatabase.
There are several geometry types, such as true curves, which are supported
within the geodatabase, but not in shapefiles. I have not had the chance to try
this yet, and this certainly would not play a role in my example of point data
mentioned above, but would be worth a try on your line data.
I will
submit an inquiry to my technical lead regarding this and update you as
information becomes available. Please keep me posted on the results of your
testing.
