This approach has several advantages over adding logging code to each function
separately:
??? The original code is untouched; it can be changed or upgraded without affecting
the tracing code.
??? When tracing is disabled, the code performs exactly as it did before tracing; the
tracing code is invisible in stack traces. There is no performance overhead when
tracing is disabled.
Examples | 43
However, there are some disadvantages to writing what is essentially self-modifying
code:
??? Tracing is only available at the function level. More detailed tracing would
require changing or patching the original code. Rails code tends to address this
by making methods small and their names descriptive.
??? Stack traces do become more complicated when tracing is enabled. With tracing,
a stack trace into the Person#refresh method would have an extra level:
#refresh_with_timing, then #refresh_without_timing (the original method).
??? This approach may break when using more than one application server, as the
functions are aliased in-memory. The changes will not propagate between servers,
and will revert when the server process is restarted. However, this can actually
be a feature in production; typically, you will not want to profile all traffic in
a high-traffic production environment, but only a subset of it.
Rails Routing Code
The Rails routing code is perhaps some of the most conceptually difficult code in
Rails.
Pages:
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77