0

I need to deal with some data that, in most cases, do not need to be written to disk. I'm using SQLAlchemy to deal with database operations. These data are from json strings. For example, 

from sqlalchemy import String, Column
from sqlalchemy.ext.declarative import declarative_base

Base = declarative_base()
class Class1(Base):
    __tablename__ = 'table'

    data = Column(String)
    #and some other data members
    @staticmethod
    def parse(json_):
        #parse the json and return a list of Class1 instances

class Class2():
    __init__(self, data):
        self.data = data
        #and some other data members
    @staticmethod
    def parse(json_):
        #parse the json and return a list of Class2 instances

Basically, these two class are the same except that Class1 can deal with database and Class2 cannot. Is there any performance difference between the two class when

  1. Create instances from json,
  2. Normal operations such as read data from a instance?

If there are performance difference, is there a good solution that can eliminate it while keeping DRY?

iuradz
  • 1,128
  • 1
  • 12
  • 25

2 Answers2

1

Based on your example code there isn't anything visible which would cause notable performance difference.

However you should benchmark the result for yourself if you believe there are micro-optimization which may help in your specific workflow.

See: Profiling Python How can you profile a python script?

Community
  • 1
  • 1
Mikko Ohtamaa
  • 82,057
  • 50
  • 264
  • 435
1

There is certainly some difference, as the machinery of SQLAlchemy pulled in through the Base-class adds some overhead. But you are asking the wrong question. There might be a performance difference, but if it is crucial to your program, so that it justifies violating DRY principles, doesn't depend on this difference itself, but what you actual program overall does, and how it performs.

If it's fast enough to do its job - don't bother. If it is not fast enough, profile. See where your real bottlenecks are, don't anticipate.

deets
  • 6,285
  • 29
  • 28
  • There's a similar problem but different problem. If I have a client/server program. The server need to write the data to database while the client do not. I don't think it's a good idea to use SQLAlchemy classes in client, but writing two different class in client and server is neither a good idea. – iuradz Aug 16 '15 at 15:32
  • If you don't want an answer to your question, ask a different question. And I'm not sure if hypothetical chasing is what SO is about. If your question is "can I write a complex meta library to generate plain and SQLAlchemy derived classes" the answer is yes. But if that's feasible is again not answerable in broad terms. A user-class in the client might serve different purposes than on the sever - so it might be warranted to write two different implementations. It might also not be - but again, that needs concrete problems. Speculating is not helpful here. – deets Aug 16 '15 at 16:16
  • And a complex meta library incurs maintenance and approachability problems that might as well set off the value of minimizing DRY. DRY and similar rules of thumbs are no absolutes. Getting a feel on where they are needed and where not comes with experience in general, but also your actual problem. – deets Aug 16 '15 at 16:20