I have the rails antipatterns book and I am doing some refactoring. Is
there a big resource difference between a rails model backed with a db
table
and just a regular model other than the metaprogramming methods being
defined for the rails model/table
Chris H. wrote in post #974022:
I have the rails antipatterns book and I am doing some refactoring. Is
there a big resource difference between a rails model backed with a db
table
and just a regular model other than the metaprogramming methods being
defined for the rails model/table
Resource difference? You mean in terms of performance or something
else? I’m not sure I get what you’re asking…
Best,
Marnen Laibow-Koser
http://www.marnen.org
[email protected]
Ya, memory usage, system performance and such.
anybody?
On 12 January 2011 17:59, Me [email protected] wrote:
anybody?
Perhaps you could explain in more detail what you mean. Give an
example of the comparison you are trying to make.
Colin
rails models:
class me
end
class me < ActiveRecord::Base
end
Does the rails AR one use much more system resources than the ruby
class?
Other than the methods being defined for the AR one.
On 12 January 2011 18:15, Me [email protected] wrote:
rails models:
class me
end
class me < ActiveRecord::Base
end
Does the rails AR one use much more system resources than the ruby class?
Other than the methods being defined for the AR one.
Are you asking whether a class derived from ActiveRecord::Base uses
more resources than one not so derived, apart from the resources used
by ActiveRecord::Base? Sorry that seems to me to be not a useful
question to ask. As I said previously if you could give some
background as to why you are asking the question it may make more
sense to me.
Colin
OK from my first post. I am refactoring trying to make my app lean and
agile. The less models loaded up the less memory obviously. I was
curious
if refactored out the DB portion and left the ruby model if it would
have a
noticeable impact or whether getting rid of the model and refactor into
another on needed is a better way to lean the app. I am following the
Rails anitpatterns book for this stuff.
not sure what else to say. If you have a db table with 2 lines that are
never going to change. You refactor that into the other model that
references it and remove the original AR model. I was wondering, when
you
remove the table if you were to keep the original model but refactor the
stuf into that mode instead of the referring model does it consume the
same
memory, BW, whatever, as opposed to the AR version of the model.
On 12 January 2011 18:32, Me [email protected] wrote:
Please quote the previous message and insert your comments at the
appropriate points. It makes it easier to follow the thread. Thanks.
OK from my first post. I am refactoring trying to make my app lean and
agile. The less models loaded up the less memory obviously.
Not necessarily. In terms of resources just loading models I would
think it is more down to lines of code than number of models.
I was curious
if refactored out the DB portion and left the ruby model if it would have a
noticeable impact
Perhaps I am being particularly dense today, again I do not understand
what you mean by refactoring out the db portion and leaving the Ruby
model.
or whether getting rid of the model and refactor into
another on needed is a better way to lean the app.
Do you mean combining non-AR models or what?
Colin
Just to be clear, what specific performance tests are you having a
problem with?
Refactoring for better readability/maintainability every time your tests
are green is a good practice.
Trying to make micro-optimizations in memory profile, sql queries,
caching, etc without a specific failing performance test and profiling
results showing which query or page load is causing the problem just
burns time and obfuscates your code. Apart from anything else, the
things that make your app slow are probably not those that you expect it
to be.
The only thing I would say is that if you have a transient object that
doesn’t require persistence (I have a location object in a new app - I
don’t store locations - I just use them to handle geocoding and to
return a list of places from a third party service) from what I
understand (I’m still new to best Rails practices), it’s quite
reasonable to put that in the lib directory. I wouldn’t wrap an entire
AR lifecycle around a Class that I did not plan to persist the instances
of. But that’s not to improve performance (although it might in some
way) but because it seems more semantically accurate - it better
expresses my intent.
Best Wishes,
Peter
I would think that a select box populated by an array or hash is MUCH
faster
and less system intensive than doing any db lookup.
On 12 January 2011 21:14, Me [email protected] wrote:
To repeat, please quote the message you are replying to. Thanks
not sure what else to say. If you have a db table with 2 lines that are
never going to change. You refactor that into the other model that
references it and remove the original AR model. I was wondering, when you
remove the table if you were to keep the original model but refactor the
stuf into that mode instead of the referring model does it consume the same
memory, BW, whatever, as opposed to the AR version of the model.
A key fact missing previously was that you have a very small table and
could just hard code the data.
The answer is who cares? Don’t worry about it unless you have
performance or resource problems, in which case profile the code to
find out where the problem lies and then address it. I can virtually
guarantee that the bottlenecks or resource hogs will not be in the
areas you might anticipate beforehand.
Colin
It probably is, but why were you putting the data into a database? If
there’s a valid reason to do that, do it and then fix db performance
with caching if it becomes a limiting factor.
If there’s not a valid reason to put the data into a database, why would
you do so? Start with the simplest thing that would possibly work to get
your tests passing and go from there.
There was some discourse on one of the agile-like lists (maybe the XP
list) recently with some people suggesting you shouldn’t actually add
support for a db to an app until you have the first test that won’t pass
simply by using in memory representations. That’s a little extreme for
me, but certainly I wouldn’t put stuff into a db unless there was a good
reason. And if there is a good reason for it being there, I wouldn’t
remove it for performance reasons until I had failing performance tests
and profiling that pointed to that query as being part of my problem.
Google “premature optimization”
Best Wishes,
Peter
Maybe so but you do not have to 3rd level normalize EVERY thing in a db.
I
learned to normalize your tables. BUT, now if you have only several
items
that are fixed that are not going to change it is beter to NOT put it in
the
db if you are not going to change it or need it to create an interface
to
manage it.
Peter B. wrote in post #974422:
It probably is, but why were you putting the data into a database? If
there’s a valid reason to do that, do it and then fix db performance
with caching if it becomes a limiting factor.If there’s not a valid reason to put the data into a database, why would
you do so? Start with the simplest thing that would possibly work to get
your tests passing and go from there.
[…]
With Rails, sometimes using a DB is the simplest thing, and it’s
actually harder not to do so. But I agree with the sentiment.
Best,
Marnen Laibow-Koser
http://www.marnen.org
[email protected]
Please quote when replying.
Chris H. wrote in post #974782:
Maybe so but you do not have to 3rd level normalize EVERY thing in a db.
Yes, you absolutely do have to normalize at least to 3NF. The only
excuse for a denormalized schema is if you’ve actually measured that
you’ve got a performance bottleneck that denormalization will solve
(note: in 11 years of Web application development, I’ve never once had
to do this).
I
learned to normalize your tables. BUT, now if you have only several
items
that are fixed that are not going to change it is beter to NOT put it in
the
db if you are not going to change it or need it to create an interface
to
manage it.
Often true. But that’s a separate issue.
Best,
Marnen Laibow-Koser
http://www.marnen.org
[email protected]
On Jan 14, 2011, at 12:23 AM, Marnen Laibow-Koser wrote:
Please quote when replying.
Chris H. wrote in post #974782:
Maybe so but you do not have to 3rd level normalize EVERY thing in a db.
Yes, you absolutely do have to normalize at least to 3NF. The only
excuse for a denormalized schema is if you’ve actually measured that
you’ve got a performance bottleneck that denormalization will solve
(note: in 11 years of Web application development, I’ve never once had
to do this).
i think 11 years create u too old school… 3fn in web development? our
dude, so if u like problems -))
if u use rails, ar- pattern, thinkin in models, not in database schema.
- counter_caches columns (helpfull in development)
Ivan N. wrote in post #974793:
On Jan 14, 2011, at 12:23 AM, Marnen Laibow-Koser wrote:
Please quote when replying.
Chris H. wrote in post #974782:
Maybe so but you do not have to 3rd level normalize EVERY thing in a db.
Yes, you absolutely do have to normalize at least to 3NF. The only
excuse for a denormalized schema is if you’ve actually measured that
you’ve got a performance bottleneck that denormalization will solve
(note: in 11 years of Web application development, I’ve never once had
to do this).i think 11 years create u too old school…
And I think you don’t know what you’re talking about.
3fn in web development? our
dude, so if u like problems -))
3NF solves problems. What problems do you think it creates?
if u use rails, ar- pattern, thinkin in models, not in database schema.
- counter_caches columns (helpfull in development)
No! When working with SQL databases, you have to understand and work
with the database. When working with objects, you have to understand
and work with the objects. Fortunately, AR lets you do both
simultaneously if you know what you’re doing.
And counter_cache should be considered a cheap performance hack, nothing
more. It’s not necessary from a design standpoint if your data model is
correct.
Best,
Marnen Laibow-Koser
http://www.marnen.org
[email protected]
Sent from my iPhone