The property names are serialized in the entity's protobuf, so there will be a performance impact. However, it's probably not measurable; "even a tiny one" may be overstating the magnitude.
In terms of storage space, however, you might see a noticeable impact, especially if your actual data is fairly small and you have a huge number of entities and indexes on them; a few extra bytes in the name of a giant TextProperty won't be noticeable, but long names for each of 20 IntegerProperties with indexes on them will likely make your metadata take up more storage space than your actual data. Of course, making your code unreadable with meaningless variable names to save a little space might be a bad decision in the long run... On Jun 17, 4:33 pm, Blake <[email protected]> wrote: > I'm curious as to whether field name lengths impact performance when > you have a high volume of writes on a very simple object type to the > datastore. > > I know it's not the case for relational dbs, but for the datastore I'm > not certain how field names are stored/maintained for every object of > a particular type as those fields can vary amongst those objects. > > As an example, if I have a small model, all ints like this: > > class Example(db.Model): > some_id = db.IntegerProperty() > first_integer = db.IntegerProperty() > second_integer = db.IntegerProperty() > > Is there any performance impact (even a tiny one) when doing very > frequent writes when compared to something like this: > > class Example(db.Model): > s = db.IntegerProperty() > i = db.IntegerProperty() > j = db.IntegerProperty() -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
